Error when using Semaphore>>wait:

The following code throws an exception "Primitive failed" in DPRO 5.1.4:

        Semaphore new wait: 100

Am I doing something wrong here or is this a bug? I'd like my Semaphore
to wait for a maximum of 100ms to be signalled.

Bernhard

Bernhard,

> The following code throws an exception "Primitive failed" in DPRO 5.1.4:
>
>     Semaphore new wait: 100
>
> Am I doing something wrong here or is this a bug? I'd like my Semaphore
> to wait for a maximum of 100ms to be signalled.

Look at the method comment for Semaphore>>wait:ret:  It states ...

"At present the only valid values for timeout are,  INFINITE, meaning
wait for ever, and 0, meaning don't wait at all. The behaviour of these
is as follows:"

... which explains why you get the walkback with a timeout value of 100.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Ian Bartholomew wrote:

> Look at the method comment for Semaphore>>wait:ret:  It states ...
>
> "At present the only valid values for timeout are,  INFINITE, meaning
> wait for ever, and 0, meaning don't wait at all. The behaviour of these
> is as follows:"
>
> .... which explains why you get the walkback with a timeout value of 100.
>

Thanks Ian, I completely overlooked that. Is that going to be changed in
  Dolphin 6?

Bernhard

Bernhard,

> Thanks Ian, I completely overlooked that. Is that going to be changed in
>  Dolphin 6?

Afraid not, the code has not been changed for D6 and the same walkback
is raised.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Bernhard Kohlhaas escribió:
> The following code throws an exception "Primitive failed" in DPRO 5.1.4:
>
>     Semaphore new wait: 100
>
> Am I doing something wrong here or is this a bug? I'd like my Semaphore
> to wait for a maximum of 100ms to be signalled.
>
> Bernhard

Why don't use a Delay object?

(Delay forMilliseconds: 100) wait.

Best regards.


--
Esteban

Esteban,

I'm not 100% about this, but I think the problem is rather how to program a timeout on a particular action.

A simple Delay wouldn't solve that.

Günther

Günther Schmidt wrote:
> Esteban,
>
> I'm not 100% about this, but I think the problem is rather how to
> program a timeout on a particular action.
>
> A simple Delay wouldn't solve that.
>
> Günther


Exactly! The code just showed the error, what I was attempting was
something like:

        | sem timeout |
        sem := Semaphore new.
        timeout := 10000.
        [ "Some longer running action here". sem signal ] fork.
        sem wait: timeout.

to get a timeout, if the async process doesn't complete the action in
the amount of time. For the time being, I've added a method
Semaphore>>waitForMaxMilliseconds: which combines the immediate timeout
with an appropriate delay:

        waitForMaxMilliseconds: milliseconds
                | answer |
                milliseconds timesRepeat:
                        [answer := self wait: 0.
                        answer = WAIT_OBJECT_0 ifTrue: [^answer].
                        Processor sleep: 1].
                ^answer

Best Regards,
Bernhard

Bernhard wrote:

 > For the time being, I've added a method
I shouldn't really do this things (or at least not publish them ;) )
before my first cup of coffee, because the code above has enough holes
to drive a truck through. This is what I am now using:

        waitForMaxMilliseconds: milliseconds
        | expires |
                expires := Time millisecondClockValue + milliseconds.
                [Time millisecondClockValue < expires] whileTrue:
                                [(self wait: 0) = WAIT_OBJECT_0 ifTrue:
                                        [^WAIT_OBJECT_0].
                                Processor sleep: 1].
                ^self wait: 0

Regards,
Bernhard

Hi Günther,

Günther Schmidt escribió:
> I'm not 100% about this, but I think the problem is rather how to
> program a timeout on a particular action.
> A simple Delay wouldn't solve that.

Surely it wouldn't solve that, at least alone.

Sorry, this Moz Thunderbird tends to send messages without my
confirmation :-O

I continue my post below...

Esteban A. Maringolo escribió:
> Hi Günther,
>
> Günther Schmidt escribió:
>
>> I'm not 100% about this, but I think the problem is rather how to
>> program a timeout on a particular action.
>> A simple Delay wouldn't solve that.
>

I was saying...

> Surely it wouldn't solve that, at least alone.

What I would do is (without modifying anything in Dolphin):

| sem timeout signaler process |
sem := Semaphore new.
timeout := 2000.
signaler := [
                [(Delay forMilliseconds: timeout) wait]
                        ensure: [sem signal. process kill]
        ] newProcess.
process := [signaler resume. "Long excution goes here."] fork .
sem wait.

Sure it isn't beautiful, but it did solve my few (no performance
required) timeout requirements.

Best regards,

--
Esteban.

Bernhard,

> The following code throws an exception "Primitive failed" in DPRO 5.1.4:
>
>     Semaphore new wait: 100
>
> Am I doing something wrong here or is this a bug? I'd like my Semaphore
> to wait for a maximum of 100ms to be signalled.

You might want to try my TimedEvaluators package, which is part of my
goodies.  It might take some tweaking to get down to 0.1 sec; IIRC, the
delays are all measured in seconds.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Esteban A. Maringolo wrote:

Esteban,

Thanks for the feedback. That looks like the best approach in the case
where the state of the semaphore isn't really needed afterwards.

One question though: Shouldn't the statement
   process := [signaler resume. "Long excution goes here."] fork .
rather be
   process := [signaler resume.
               "Long excution goes here."
               sem signal ] fork .

so that the waiting process continues immediately, if the process is
finished before the signaler is?

Best Regards,
Bernhard

Bernhard Kohlhaas escribió:
Yes yes, I forgot to write it.
However, I don't know what would happen to the semaphore if the long
exec process ends before timeout, it could be signaled twice, one in
the signaler process, and another in the long execution one.

Regards,

--
Esteban.

Esteban A. Maringolo wrote:
>
> Yes yes, I forgot to write it.
> However, I don't know what would happen to the semaphore if the long
> exec process ends before timeout, it could be signaled twice, one in the
> signaler process, and another in the long execution one.

To the best of my knowledge the semaphore would remember the 2nd signal,
so it would complete the next wait immediately. So if that code section
is executed repeatedly, the semaphore would need to be reset each time
or a new semephore could be instantiated instead.

Regards,
Bernhard

Bill Schwab wrote:
>
> You might want to try my TimedEvaluators package, which is part of my
> goodies.  It might take some tweaking to get down to 0.1 sec; IIRC, the
> delays are all measured in seconds.

Bill, that looks very useful.

Thanks so much,
Bernhard