Hi Eliot,
> Hi Jaromir,
>
> On Sat, Jan 22, 2022 at 3:57 AM Jaromir Matas <mail at jaromir.net> wrote:
>
> >
> >
> > Hi Eliot,
> >
> > I’d like to test it but the build failed for Windows and Mac; not sure
> > what it means…
> >
> > Sorry to hear the current “incorrect” suspend behavior has been exploited
> > more than expected in the existing code.
> >
>
> It's not the incorrect suspend behaviour that's being exploited, it's the
> return value of suspend. Existing code appears to depend on the
> semaphore/mutex a process is blocked on being answered by suspend.
Yes, that's what I meant, actually :) I understand knowing the list was vital to e.g. recognize whether the process was blocked or runnable (#releaseCriticalSection).
> What would you think about having primitiveSuspendV2 return self instead of
>
> > any list at all – to make all state changing methods answer consistently
> > (like e.g. VW do)… if the answer expected by the “affected” code base has
> > to be provided by primitiveSuspend anyways.
> >
>
> I don't see this is at all useful. If one isn't interested in the
> semaphore/mutex return value one does not have to examine it. But there is
> no way of getting the list once the process has been removed from it other
> than by having the suspend primitive answer it.
Well yes, it surely is more useful to return something in addition to the powerful side effect :) I was just wondering if it's not a "temptation" to be better avoided. I suggested in another post the list is still available on the suspendedContext's stack should someone really want it. But I'm just inquiring here to satisfy my curiosity, sorry.
> So if one isn't interested in the return value simply write something of
> the form
>
> aProcess suspend; yourself
>
> But if one *is* interested in the result then the primitive better
> answer it, nbo?
Oh, if there's a use case even with the new primitiveSuspendV2 then no doubt.
Thanks again for sharing your thoughts!
Best,
Jaromir