I don't have time to look at this properly until tomorrow.
In the meantime, could you just post the result of...

   Delay delaySchedulerClass
it should be "DelayExperimentalSpinScheduler"   ***

Also could you try a few of the other options from
 World > System > Settings > System ...


***whoops, the Experimental tag should have been dropped for Pharo 5
Release.  Its been fine for months (unless this is a fault :)  ]

On Wed, May 18, 2016 at 11:49 PM, Mariano Martinez Peck
<marianop...@gmail.com> wrote:
> Hi guys,
>
> I am seeing a problem in Pharo 5.0 regarding Delay >> wait. I cannot explain
> how this could happened but it does, and it happened to me a couple of times
> (but not fully reproducible).
>
> In OSSubprocess I have this child watcher:
>
> initializeChildWatcher
> "This is a process which waits for the death of a child processes. Use
> SIGCHLD events rather than a Delay to poll."
>
> | processSynchronizationDelay |
> processSynchronizationDelay := Delay forMilliseconds: 20.
> childWatcher ifNil: [
> childWatcher := [[
> "OSProcess authors suspected that there were various ways in which OS
> signals
> could be missed under conditions of heavy load. For that reason, we use
> #waitTimeoutMSecs: with the semaphore, so that if a signal is missed,
> we time out and rescan occasionally anyway
> (#updateActiveChildrenAndNotifyDead
> sends queryExitStatus which sends waitpid() )
> "
> self sigChldSemaphore waitTimeoutMSecs: 1000.
> processSynchronizationDelay wait. "Avoids lost signals in heavy process
> switching"
> self updateActiveChildrenAndNotifyDead.
> ] repeat] newProcess.
>
> childWatcher resume.
> "name selected to look reasonable in the process browser"
> childWatcher name: ((ReadStream on: childWatcher hash asString) next: 5)
> , ': the OSSubprocess child watcher'
> ]
>
>
> The problem is that now above process is hung on the
> "processSynchronizationDelay wait.". At least that's what I can see from the
> process browser.  That should not hung, of course, and should stop waiting
> after 20 ms.
>
> If I inspect the Delay instance in question (doing the wait) I see that the
> print string is bad.... "a Delay(20 msecs; 3641032396485 msecs remaining)".
> WTF? 20ms  and you remain 3641032396485 to wait??? I attach an screenshot of
> the Delay instance in case there could be something wrong.

>
> Maybe it is wrong to keep and re-use same instance of Delay? (note it is
> outside the closure) (this was not a problem in the past).

Not sure.  I've heard others say Delays should only be used once. To
experiment, could you try creating a delay each time.

cheers -ben

Reply via email to