unlimited (was Re: task notepad question)

[Joel Sherrill]

Chris Johns wrote:
> 
> Joel Sherrill wrote:
> 
> > Chris Johns wrote:
> >
> > >Joel Sherrill wrote:
> > >
> > >>NOTE: The set of POSIX keys is not enlarged if you use unlimited tasks.
> > >
> > >Does the user get the correct error code in the current code ?
> >
> > What would it be and who would trigger it?  All tasks/threads are
> > supposed to have a key slot.
> 
> Does a POSIX app that creates more threads than keys with the task
> number set to unlmited handle the error correctly ?

I think you are missing the relationship problem.  If you have a 
"limited" number of Classic tasks or POSIX threads, things work
great.  If you have unlimited Classic tasks or POSIX threads, things
work great EXCEPT for keys.  A POSIX key has a slot for EVERY
task/thread
regardless of the API that created it.  So when you change the maximum
number of Classic tasks or POSIX threads, the keys are not resized.

> > >Do any other parts of the POSIX API suffer from this problem or is it
> > >just threads (tasks!) ?
> >
> > I think that it is just keys.  I think you can extend the number of
> > POSIX threads.  But keys are different.
> 
> I think I need to look at the way this is implement to see the relationship.

Yep. :)  The problem is on the key side.  I think the key needs the 
opportunity to see that the maximum number of tasks/threads changed.

> >
> > >This is also the case with User Extensions and the drivers table. You
> > >can add drivers after starting, but the number is fixed. Any others ?
> >
> > I don't think this is that bad a problem.  It is just a configuration
> > limit.
> 
> I suspect this depends on where you view the configuration table
> resides. I have the configuration in the BSP not the application and the
> BSP is built separate from RTEMS, and the application. The hardware +
> bsp model.

That would make it a problem. 

> > >I can raise a PR for this and list all the areas that need to be
> > looked at.
> > >
> > >I have not looked at the POSIX implementation so far :-). Are keys
> > >handled in one spot ?
> >
> > As much as anything in RTEMS... see cpukit/posix/src/key*.c.  The
> > problem is that there is no event/API hook when the number of
> > tasks/threads increases.  Look at keycreate.c and you will see the
> > problem.
> 
> Maybe I am missing something here. The keys are objects
> (_POSIX_Keys_Allocate) so setting object info structure's auto_extend to
> true will result in unlimited keys.
> 
> I do not understand the api loop.

A key is like a per-task variable.  Each task/thread has a unique
location.
So you ask for the value for Key X for thread/task Y.  It is a unique
pairing.  A key must have a slot for each task/thread possible in the
system.

From
http://www.opengroup.org/cgi-bin/dbcgix?TPL=sd_formframes&TOKEN=BWBNB&override=sd_search

> The pthread_key_create() function creates a thread-specific data key visible to all threads in the process. Key values provided by pthread_key_create() are opaque objects used to locate
>      thread-specific data. Although the same key value may be used by different threads, the values bound to the key by pthread_setspecific() are maintained on a per-thread basis and persist for the
>      life of the calling thread. 


> --
>   Chris Johns, cjohns at cybertec.com.au

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985