On Sat, Jul 4, 2020 at 1:13 AM wrote:
> This thought is intended to be evaluated, not adopted. What I meant was I
> think you have a "bitmask" of threads that need access to a stack that is
> similar to a "bitmask" of threads/processes that may be blocked in select.
> The select-mask is a major
This thought is intended to be evaluated, not adopted. What I meant was I
think you have a "bitmask" of threads that need access to a stack that is
similar to a "bitmask" of threads/processes that may be blocked in select.
The select-mask is a major focus across operating systems. That's why I
My thought is that it matches what is needed and is expected to be optimized.
> On Jul 3, 2020, at 24:37 , Utkarsh Rai wrote:
>
>
>
> On Fri, Jul 3, 2020 at 1:32 AM Peter Dufault wrote:
> I finally have gotten to reviewing Utkarsh's work in GSOC. One item that I
> don't like is that there i
On Fri, Jul 3, 2020 at 1:32 AM Peter Dufault 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 ar
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'
