DUE TO SPAM, SIGN-UP IS DISABLED. Goto Selfserve wiki signup and request an account.
...
This separation of user and OS interfaces has not been implement as of this writing.
Wild Ideas
The primary beneficiary of TLS is the C library. The TLS interfaces are non-standard and should not be used directly by any portable application code. However, these non-standard TLS interfaces can be used within the C library to implement improved, standard user interfaces.
Local Process ID
Another unrelated data item that should, eventually, be included in the TLS data is the process ID (pid) if the currently exectuting thread. In some analysis of PROTECTED and KERNEL builds, it was found that getpid() was the most highly accessed OS interface. By moving the pid into TLS, we could eliminate this system call overhead (at least in the aligned TLS case).
Re-Entrant getopt()
getopt() is an important C library function used by applications for parsing of task comman line paramters. It is, however, not re-entrant due to the use of global variables: optarg, opterr, optind, and optopt. There are several, non-standard implementations for a re-entrant version of called getopt_r(), however, these are all wildly different and do not conform to any standard. Non-standard interfaces are not desirable in NuttX.
In the FLAT and PROTECTED builds, this non-reentrant limitation poses a problem. Unlike the protected mode, there is one instance of of the globals optarg, opterr, optind, and optopt shared across all tasks. It is not such a problem in the KERNEL build where there is a separate instance of the globals in each process address space.
Using TLS, however, it could be possible to make getopt() thread-safe using TLS. This would amount to keeping the getopt() globals in TLS so that there is an individual copy for each thread. That would keep both the standard form of the getopt() interfaces as well as making getopt() full re-entrant.
Code References
Things to look at:
...