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