On Wed, Mar 24, 2021, at 10:37, Gregory Nutt wrote: > > > 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? > > You would expect getopt() to be used only on the many thread since that > is the only thread that receives argc and argv.
So if it is only used in one thread there would only be a copy of the data? What if I spawn multiple threads and call getopt only on one? > > A faithful, bug-for-bug, implementation would require a per task, but > AFAIK there would be no real problem with per thread either. Yes, my thinking is that getopt() does not provide thread safety guarantees but it is not wrong to provide them. I think that some obscure case of changing getopt() globals from different threads is worst to support than just not doing anything in our case. > > > > > 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. > > Except that NuttX is a standards based OS and we avoid non-standard > interfaces like the plague. Using TLS is 100% transparent and 100% > compatible. Why would you adopt a non-standard solution when a better, > fully compliant implementation is readily available? My thinking is that this could be a case of something that in FLAT mode would give the wrong results if just used as is and the non-standard function allows to overcome this. But of course if the TLS solution is the right approach and does not incur in extra resource usage, the extra function would of course not be needed. My concern was that "the right approach" would incur in too much resource usage. But again, I don't understand how TLS works yet. Best, Matias
