Thanks for all answers. I don't entirely understand most of them though as I'm 
not really familiar with the implications of TLS or how to use it correctly. 
Also, do we need per-thread or per-task data here? 

What I'm thinking is that, besides the TLS based solution, adding a 
non-standard getopt() seems to be a good option anyway, since it is a 
lightweight solution to this particular function.

So, how should we proceed to address this somehow? 

Best,
Matias

On Wed, Mar 24, 2021, at 10:22, Gregory Nutt wrote:
> 
> >> The custom handler isn't enough here, because the real problem is we need
> >> the global variables per task/process.
> >> As Greg suggests, we need something like TLS but per task/process not per
> >> thread(e.g. task_getspecific/task_setspecific).
> >> Once the mechanism is done, getopt can be converted to confirm the standard
> >> trivally.
> >>
> > I was looking at this exact issue last week (see comment in
> > https://github.com/apache/incubator-nuttx/pull/3054).
> >
> > The basis for this mechanism exists in the way errno is handled. Perhaps a
> > structure defined for all libc globals added to TLS and a call from the
> > task creation code to initialise it?
> 
> That would, of course, make the stack usage much larger.  Perhaps an 
> allocate-on-demand approach would make that doable.
> 
> POSIX thread specific data has a good, interface for such 
> allocate-on-demand usage.  POSIX thread specific data is built on top of 
> TLS.
> 
> 
> 

Reply via email to