unlimited (was Re: task notepad question)

[Chris Johns]

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 ?

> >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.

>
> >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.

> >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.

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