Re: avoiding pitfal of reuse of globals in FLAT mode?

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. Why do you think TLS is not lightweight.  It is very lightweight. The non-standard, non-portable

Re: avoiding pitfal of reuse of globals in FLAT mode?

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. Why do you think TLS is not lightweight.  It is very lightweight. The non-standard, non-portable

Re: avoiding pitfal of reuse of globals in FLAT mode?

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. Why do you think TLS is not lightweight.  It is very lightweight.  The non-standard, non-portable

Re: avoiding pitfal of reuse of globals in FLAT mode?

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

Re: avoiding pitfal of reuse of globals in FLAT mode?

On Wed, Mar 24, 2021, at 19:27, Byron Ellacott wrote: > Here's what I found in libc that would need task (thread) specific data: > > - libs/libc/misc/lib_umask.c has g_mask > - libs/libc/libgen/lib_dirname.c and libs/libc/libgen/lib_basename each > have a g_retchar > -

Re: avoiding pitfal of reuse of globals in FLAT mode?

On Thu, Mar 25, 2021 at 8:27 AM Byron Ellacott wrote: > Hi, > > Since the basic problem is that `getopt` doesn't have a per-task value it > can use, how would it keep track of which TLS key it's been allocated? > This question, at least, I understand the answer to having looked at the PR - the

Re: avoiding pitfal of reuse of globals in FLAT mode?

Hi, Since the basic problem is that `getopt` doesn't have a per-task value it can use, how would it keep track of which TLS key it's been allocated? Here's what I found in libc that would need task (thread) specific data: - libs/libc/misc/lib_umask.c has g_mask -

Re: avoiding pitfal of reuse of globals in FLAT mode?

Great, thanks! I was just writing an issue to have this noted somewhere. Best, Matias On Wed, Mar 24, 2021, at 13:23, Gregory Nutt wrote: > I think it is not very much work to implement. Perhaps I will submit a > draft PR for your review. > > > On 3/24/2021 9:34 AM, Matias N. wrote: > > Yes,

Re: avoiding pitfal of reuse of globals in FLAT mode?

I think it is not very much work to implement.  Perhaps I will submit a draft PR for your review. On 3/24/2021 9:34 AM, Matias N. wrote: Yes, you're right, TLS is the way to go. I only wonder how to minimize the impact. Could this array inside the TLS struct be grown as needed during

Re: avoiding pitfal of reuse of globals in FLAT mode?

Yes, you're right, TLS is the way to go. I only wonder how to minimize the impact. Could this array inside the TLS struct be grown as needed during runtime? That way if no application calls to getopt() (or any other function requiring similar solution), no extra space on TLS is used. On Wed,

Re: avoiding pitfal of reuse of globals in FLAT mode?

Se we can either add something special just as for errno or use entries in that array (which would require establishing a minimum number of entries to satisfy the case of getopt en potentially others). I think it is better to somehow "reserve" space for the known required cases. What

Re: avoiding pitfal of reuse of globals in FLAT mode?

Se we can either add something special just as for errno or use entries in that array (which would require establishing a minimum number of entries to satisfy the case of getopt en potentially others). I think it is better to somehow "reserve" space for the known required cases. What i'm

Re: avoiding pitfal of reuse of globals in FLAT mode?

Se we can either add something special just as for errno or use entries in that array (which would require establishing a minimum number of entries to satisfy the case of getopt en potentially others). I think it is better to somehow "reserve" space for the known required cases. What i'm

Re: avoiding pitfal of reuse of globals in FLAT mode?

On 3/24/2021 8:38 AM, Matias N. wrote: So, if I follow correctly, we could maybe have one TLS pointer pointing to a struct of pointers, one per each group of globals (one of this groups, would be the set of variables used by getopt()), like: struct task_globals_s { struct getopt_globals_s

Re: avoiding pitfal of reuse of globals in FLAT mode?

So, if I follow correctly, we could maybe have one TLS pointer pointing to a struct of pointers, one per each group of globals (one of this groups, would be the set of variables used by getopt()), like: struct task_globals_s { struct getopt_globals_s *getopt_globals; /* ...others */ };

Re: avoiding pitfal of reuse of globals in FLAT mode?

Of course, I would only call getopt() once. My question was if we use TLS, would the memory use scale with the number of threads? Or would this memory for getopt() only be allocated on getopt() calls? Yes and yes, but the memory use might be as small as a single pointer.  Per task data

Re: avoiding pitfal of reuse of globals in FLAT mode?

Of course, I would only call getopt() once. My question was if we use TLS, would the memory use scale with the number of threads? Or would this memory for getopt() only be allocated on getopt() calls? On Wed, Mar 24, 2021, at 10:56, Gregory Nutt wrote: > > >> You would expect getopt() to be

Re: avoiding pitfal of reuse of globals in FLAT mode?

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? It is hard to imagine how you

Re: avoiding pitfal of reuse of globals in FLAT mode?

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

Re: avoiding pitfal of reuse of globals in FLAT mode?

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

Re: avoiding pitfal of reuse of globals in FLAT mode?

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

Re: avoiding pitfal of reuse of globals in FLAT mode?

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

Re: avoiding pitfal of reuse of globals in FLAT mode?

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

RE: avoiding pitfal of reuse of globals in FLAT mode?

> For getopt() I see there's even no standard getopt_r(), so we would have to provide our own, which may not be a bad idea. Here is the one we have been using. https://github.com/PX4/PX4-Autopilot/commit/eab32572f42f8e3e715b952512b6f5 df9041f848

Re: avoiding pitfal of reuse of globals in FLAT mode?

On Wed, Mar 24, 2021 at 2:08 PM Xiang Xiao wrote: > On Wed, Mar 24, 2021 at 9:18 AM Matias N. wrote: > > > > > > > - devise a mechanism to mimic what would be done by OS in KERNEL mode > > (add > > > > > some custom handler to APIs internally using globals, such as getopt, > > that can be > > >

Re: avoiding pitfal of reuse of globals in FLAT mode?

On Wed, Mar 24, 2021 at 9:18 AM Matias N. wrote: > > > On Tue, Mar 23, 2021, at 22:09, Nathan Hartman wrote: > > On Tue, Mar 23, 2021 at 8:39 PM Matias N. matias%40imap.cc>> wrote: > > > > > Hi, > > > while using getopt() from a task started from NSH I realized subsequent > > > calls reused the

Re: avoiding pitfal of reuse of globals in FLAT mode?

One option is to replace the globals with accessor functions and use TLS to hold the actua. data.Sent from my Galaxy Original message From: "Matias N." Date: 3/23/21 7:18 PM (GMT-06:00) To: dev@nuttx.apache.org Subject: Re: avoiding pitfal of reuse of globals in FLAT mode?

Re: avoiding pitfal of reuse of globals in FLAT mode?

On Tue, Mar 23, 2021, at 22:09, Nathan Hartman wrote: > On Tue, Mar 23, 2021 at 8:39 PM Matias N. > wrote: > > > Hi, > > while using getopt() from a task started from NSH I realized subsequent > > calls reused the global optind and similar variables resulting in

Re: avoiding pitfal of reuse of globals in FLAT mode?

On Tue, Mar 23, 2021 at 8:39 PM Matias N. wrote: > Hi, > while using getopt() from a task started from NSH I realized subsequent > calls reused the global optind and similar variables resulting in different > results each time. I'm aware this is expected in FLAT mode and is related > to the