On Fri, Jun 17, 2022 at 4:12 AM Jaromir Matas <mail at jaromir.net> wrote:

> Hi Christoph,
>
>
>
> I understand now why you asked for ‘one sentence’ only to summarize
> #suspend changes to the release notes; here’s my suggestion:
>
>
>
> Revises #suspend to stop the receiver waiting on a semaphore or mutex in
> such a way that sending it the message #resume will restore receiver's
> previous waiting state.
>

How about "Revises suspend to ensure a process waiting on a semaphore or
mutex, if suspended and then resumed, will continue to wait on the
semaphore or mutex. Previously suspend would cause a process to no longer
be waiting when resumed."
It's two sentences but "to stop the receiver waiting" is potentially
confusing.


>
>
>
> *From: *Jaromir Matas <mail at jaromir.net>
> *Sent: *Thursday, June 16, 2022 16:09
> *To: *The general-purpose Squeak developers list
> <squeak-dev at lists.squeakfoundation.org>
> *Subject: *Re: [squeak-dev] New #suspend semantics
>
>
>
> Hi Christoph,
>
>
>
> Precisely; I like to use this example instead:
>
>
>
>                 p := [Semaphore new wait] fork.
>
>                 Processor yield.
>
>                 p suspend.
>
>                 p resume.
>
>                 Processor yield.
>
>                 {p isTerminated. p isBlocked}    "should answer #(false
> true)"
>
>
>
> For some reason the example with Process forBlock: produces ‘Error:
> resume fails’ in 5.3. If you make it a test, that would be great; I’ve only
> added testRevisedSuspendExpectations but it is a good idea to test
> suspend+resume behavior as well.
>
>
>
> > Revises #suspend to remember any semaphore or monitor that the receiver
> has been waiting for and restore the waiting state in #resume (the old
> behavior is available via #suspendAndUnblock).
>
>
>
> Apologies for nitpicking: “remember” is not exactly what really happens,
> #suspend ‘simply’ returns process’s pc one instruction (i.e. the send that
> invoked the wait) back; so the next resume (which may never happen if you
> e.g. terminate) just executes the send again.
>
>
>
> Eliot’s comment in #suspend expresses this nicely; maybe take it from
> there…
>
>
>
> [if a process] was on some condition variable (Semaphore, Mutex) [then]
> back up its pc to the send that invoked the wait state the process
> entered.  Hence when the process resumes it will reenter the wait state.
>
>
>
> I’ve read somewhere ‘official’ a short and exact description what suspend
> is supposed to do (not ANSI, somewhere else but can’t remember where) and
> this Eliot’s implementation does exactly that.
>
> Thanks,
> Jaromir
>
>
>
>
>
> *From: *Thiede, Christoph <Christoph.Thiede at student.hpi.uni-potsdam.de>
> *Sent: *Thursday, June 16, 2022 15:23
> *To: *The general-purpose Squeak developers list
> <squeak-dev at lists.squeakfoundation.org>
> *Subject: *Re: [squeak-dev] New #suspend semantics
>
>
>
> Hi Jaromir,
>
>
>
> thanks a lot for the summary!
>
>
>
> Translating this to code for my own understanding:
>
>
>
> p := Process forBlock: [Semaphore new wait].
>
> p resume.
>
> Processor yield.
>
> p suspend.
>
> p resume.
>
> Processor yield.
>
> {p isBlocked. p isTerminated}
>
>
>
> has answered #(false true) in the past;
>
> and now answers #(true false).
>
>
>
> > Alas, I don't seem to be able to squeeze it into one sentence or even
> less ;)
>
>
>
> Hm, I will try this:
>
>
>
> Revises #suspend to remember any semaphore or monitor that the receiver
> has been waiting for and restore the waiting state in #resume (the old
> behavior is available via #suspendAndUnblock).
>
>
>
> My question is answered then. :-)
>
>
>
> ---
>
>
>
> Please apologize that I did not read the entire linked thread. We tend to
> write so much that the pure reading time for this thread (let alone any
> comprehension) would be close to 20 minutes. =D
>
>
>
> One last quick question: Will there be tests for #suspendAndUnblock? Maybe
> something like my above example?
>
>
>
> Best,
>
> Christoph
>
>
>
> *Von:* Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im
> Auftrag von Jaromir Matas <mail at jaromir.net>
> *Gesendet:* Montag, 13. Juni 2022 08:45 Uhr
> *An:* The general-purpose Squeak developers list
> *Betreff:* Re: [squeak-dev] New #suspend semantics
>
>
>
> Hi Christoph,
>
>
>
> The difference between the new #suspend using suspend primitive 578 and
> the previous one using primitive 88 is this:
>
>
>
> Previously, if you suspended a process waiting on a semaphore or mutex the
> process was removed from the semaphore or mutex; subsequent #resume would
> let the process continue as if the process had never been waiting.
>
>
>
> The new suspend with primitive 578 not only removes the process from the
> semaphore or mutex but backs it up one instruction, i.e. before the wait
> send, and thus a subsequent #resume will allow the process go back to the
> wait on the semaphore or mutex, i.e. to the same state as before the
> suspension.
>
>
>
> One of the adverse effects of the previous behavior was #critical sections
> could have been entered multiple times regardless of the ownership of the
> condition variable.
>
>
>
> The previous behavior have been used (or misused) to cheaply escape a
> condition variable; for backward compatibility the old behavior has been
> preserved in #suspendAndUnblock.
>
>
>
> Here's more:
> http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-December/217831.html
>
>
>
> Alas, I don't seem to be able to squeeze it into one sentence or even less
> ;)
>
>
>
> Best,
>
> Jaromir
>
>
>
> --
>
> *Jaromír Matas*
>
> mail at jaromir.net
>
>
>
> *From: *christoph.thiede at student.hpi.uni-potsdam.de
> *Sent: *Sunday, June 12, 2022 21:45
> *To: *squeak-dev at lists.squeakfoundation.org
> *Subject: *[squeak-dev] New #suspend semantics
>
>
>
> Hi Jaromír,
>
> as I'm currently updating the release notes, I'm trying to figure out what
> exactly are the visible effects of your changes to #suspend and
> #suspendAndUnblock from May 30.
>
> There has been written so much about this on the list in the last months
> that it's hard to follow up. If you could just describe the changes very
> briefly, probably in one or a half sentence, that would be perfect. :D
>
> Thanks in advance,
> Christoph
>
> ---
> *Sent from Squeak Inbox Talk
> <https://github.com/hpi-swa-lab/squeak-inbox-talk>*
>
>
>
>
>
>
>
>

-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220617/e64fbd13/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: C6E11A0D91624B92934B92D3F3A3CA3B.png
Type: image/png
Size: 144 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220617/e64fbd13/attachment-0001.png>