My thought is that it matches what is needed and is expected to be optimized.
> On Jul 3, 2020, at 24:37 , Utkarsh Rai <utkarsh.ra...@gmail.com> wrote: > > > > On Fri, Jul 3, 2020 at 1:32 AM Peter Dufault <dufa...@hda.com> wrote: > I finally have gotten to reviewing Utkarsh's work in GSOC. One item that I > don't like is that there is a linked list management of the threads that have > access to the stack. > I think this access is similar to the file descriptors that are blocked in a > select call. On a given architecture I don't know exactly how many file > descriptors I can block, I don't know exactly what the FD_SET macro does, but > I have access to multiple file descriptors through the FD_* macros. > > > Hello, thank you for the feedback. If I understand your suggestion correctly, > we can specify a file descriptor set 'fd_set' and then register the stack > attributes to this set, and then check for the 'current stack' through > select() and FD_ISSET()? > > Using FD_SET and friends for specifying thread access could be a good model > to specify which threads need access to which thread. > > My question is, what benefit do we get by using FD_SET and friends? > Ultimately we will have to iterate through the set to check for the 'current > stack'. > > However, it won't scale infinitely. Linked lists won't scale infinitely in > real-time either. > > An optimization that I had in mind was to use the LRU model. This way we can > mark the stack attributes of the last thread as 'not current' without > iterating through the list or the set. > > Peter > ----------------- > Peter Dufault > HD Associates, Inc. Software and System Engineering > > This email is delivered through the public internet using protocols subject > to interception and tampering. > Peter ----------------- Peter Dufault HD Associates, Inc. Software and System Engineering This email is delivered through the public internet using protocols subject to interception and tampering. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
