Re: [Pharo-dev] about signal

2020-01-12 Thread ducasse
While working on the booklet this week-end I was wondering (now I’m too dead to think and going to sleep) whether there is a semantics difference between resuming a suspended process using the message resume and “resuming a process” as a side effect of a wait signalled. S.

Re: [Pharo-dev] about signal

2020-01-12 Thread ducasse
> > If processPreemptionYields false the output should be: > > ... > p2 > p1 > p2 > p1 > p2 > p1 > ... > > i.e. it is regular. What we're actually seeing is: > > ... > 'p1' > 'p2' > 'p1' > 'p2' > 'p2' > ... > > Which showing that p2 might get to signal multiple times before p1 > gets to

Re: [Pharo-dev] about signal

2020-01-12 Thread Alistair Grant
Hi Eliot, On Sun, 12 Jan 2020 at 18:16, Eliot Miranda wrote: > >> Hi Alastair, >> >> On Jan 12, 2020, at 12:34 AM, Alistair Grant wrote: >> >> I agree with Eliot that changing #processPreemptionYields to true by >> default would be an improvement in Pharo. It would make it easier to >> predict

Re: [Pharo-dev] about signal

2020-01-12 Thread Eliot Miranda
Hi Alastair, >> On Jan 12, 2020, at 12:34 AM, Alistair Grant wrote: > On Thu, 9 Jan 2020 at 13:01, ducasse wrote: >> >> Hi >> >> I wanted to explain >> >> | semaphore p1 p2 | >> semaphore := Semaphore new. >> p1 := [ semaphore wait. >>'p1' crTrace ] fork. >> >> p2 := [semaphore

Re: [Pharo-dev] about signal

2020-01-12 Thread Alistair Grant
Hi Ben, On Sun, 12 Jan 2020 at 15:26, Ben Coman wrote: > > Now a new consideration for whether Pharo might change the default > processPreemptionYields to false > is ThreadedFFI. Presumably it will be common for a callback to be defined at > same priority as an in-image process. > I can't

Re: [Pharo-dev] Interesting bug or feature in exception processing logic

2020-01-12 Thread Denis Kudriashov
PR is here https://github.com/pharo-project/pharo/pull/5470 чт, 19 дек. 2019 г. в 21:51, Denis Kudriashov : > чт, 19 дек. 2019 г. в 21:43, Denis Kudriashov : > >> I checked Squeak. All my examples work consistently there: UnhandledError >> handler is always triggered. >> Even more: signalling

Re: [Pharo-dev] about signal

2020-01-12 Thread Ben Coman
On Sun, 12 Jan 2020 at 20:00, Sven Van Caekenberghe wrote: > Hi Alistair, > > > On 12 Jan 2020, at 09:33, Alistair Grant wrote: > > > > On Thu, 9 Jan 2020 at 13:01, ducasse wrote: > >> > >> Hi > >> > >> I wanted to explain > >> > >> | semaphore p1 p2 | > >> semaphore := Semaphore new. > >> p1

Re: [Pharo-dev] about signal

2020-01-12 Thread ducasse
> > I also wasn't implying that we just go ahead and change it. But if it > is a possibility then I'll try changing it in my image and see how it > helps with tracking down inter-process interactions that we're > currently experiencing, and if it does introduce any showstopper > issues. Yes

Re: [Pharo-dev] about signal

2020-01-12 Thread Alistair Grant
Hi Stef, On Sun, 12 Jan 2020 at 11:28, ducasse wrote: > > Hi alistair > > > Hi > > I wanted to explain > > | semaphore p1 p2 | > semaphore := Semaphore new. > p1 := [ semaphore wait. >'p1' crTrace ] fork. > > p2 := [semaphore signal. > 'p2' crTrace ] fork. > > displays p2 and p1.

Re: [Pharo-dev] about signal

2020-01-12 Thread Alistair Grant
Hi Sven, In line below... Cheers, Alistair (on phone) On Sun., 12 Jan. 2020, 13:00 Sven Van Caekenberghe, wrote: > > Hi Alistair, > > > On 12 Jan 2020, at 09:33, Alistair Grant wrote: > > > > > > I agree with Eliot that changing #processPreemptionYields to true by > > default would be an

Re: [Pharo-dev] about signal

2020-01-12 Thread Sven Van Caekenberghe
Hi Alistair, > On 12 Jan 2020, at 09:33, Alistair Grant wrote: > > On Thu, 9 Jan 2020 at 13:01, ducasse wrote: >> >> Hi >> >> I wanted to explain >> >> | semaphore p1 p2 | >> semaphore := Semaphore new. >> p1 := [ semaphore wait. >>'p1' crTrace ] fork. >> >> p2 := [semaphore

Re: [Pharo-dev] about signal

2020-01-12 Thread Sven Van Caekenberghe
Hi Ben, > On 11 Jan 2020, at 10:50, Ben Coman wrote: > > > > On Sat, 11 Jan 2020 at 06:31, Sven Van Caekenberghe wrote: > Hi Ben, > > Great approach, though I would make one change to make your example > completely copy/paste runnable. > > Stef's original example: > > | trace semaphore

[Pharo-dev] [Pharo 8.0] Build #1103: 5466-Better-Semaphore-class-comment

2020-01-12 Thread ci-pharo-ci-jenkins2
There is a new Pharo build available! The status of the build #1103 was: SUCCESS. The Pull Request #5467 was integrated: "5466-Better-Semaphore-class-comment" Pull request url: https://github.com/pharo-project/pharo/pull/5467 Issue Url: https://github.com/pharo-project/pharo/issues/5466 Build

Re: [Pharo-dev] about signal

2020-01-12 Thread ducasse
Hi alistair >> >> Hi >> >> I wanted to explain >> >> | semaphore p1 p2 | >> semaphore := Semaphore new. >> p1 := [ semaphore wait. >>'p1' crTrace ] fork. >> >> p2 := [semaphore signal. >> 'p2' crTrace ] fork. >> >> displays p2 and p1. >> but I would like explain clearly but

Re: [Pharo-dev] about signal

2020-01-12 Thread Alistair Grant
On Thu, 9 Jan 2020 at 13:01, ducasse wrote: > > Hi > > I wanted to explain > > | semaphore p1 p2 | > semaphore := Semaphore new. > p1 := [ semaphore wait. > 'p1' crTrace ] fork. > > p2 := [semaphore signal. > 'p2' crTrace ] fork. > > displays p2 and p1. > but I would like explain