Time-limited call

I have a some monadic block myBlock with external libraries calls and I need
to limit an evaluation time by a some timeout. My code is:

semaphore := Semaphore new.

process := [
    semaphore wait.
    myBlock value.
  ] forkAt: Processor userBackgroundPriority.

timer := [
    (Delay forSeconds: timeout) wait.
    semaphore signal.
    process terminate.
 ] forkAt: Processor userBackgroundPriority.

[ process isAlive ] whileTrue.

The timeout works, but, unfortunately, myBlock never starts. Where is my
fail?

--
Dmitry Zamotkin

Dmitry,

> I have a some monadic block myBlock with external libraries calls and I
need
It seems to me that you have your semaphore signal and the delay the wrong
way round. In your timer process you wait for "timeout" seconds then release
the process to start running myBlock and then immediately terminate the
myBlock process. Hence, you'll probably see very little, if any, of myBlock
run. If you try the following I think it'll do what you want:

myBlock := [60 timesRepeat: [Sound bell. Processor sleep: 1000]]. "Beep once
a second for a minute"

semaphore := Semaphore new.
process := [
semaphore wait.
myBlock value.
] forkAt: Processor userBackgroundPriority.

timer := [
semaphore signal.
(Delay forSeconds: 10) wait.
process terminate.
] forkAt: Processor userBackgroundPriority.

You should find that myBlock beeps for 10 seconds and then the timeout
terminates it.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com
---
Are you trying too hard?
http://www.object-arts.com/Relax.htm
---

Dmitry,

> I have a some monadic block myBlock with external libraries calls and I
need
> to limit an evaluation time by a some timeout. My code is:

If the time is spent "in" the external calls, then you will have to overlap
them in order to get any benefit.  If you make a non-overlapped call to
something that doesn't return, then you will find that Dolphin will hang
until the call completes.  If you make "quick" calls to poll progress, then
you won't need to overlap.

You might also need to take considerable care with exception handling in
your (I'm assuming C++???) code to avoid problems should you terminate a
call.  I'll defer to Blair on whether that's likely to be an issue, and if
so, what you should do about it.


> The timeout works, but, unfortunately, myBlock never starts. Where is my
> fail?

In addition to Andy's reply, you might also have a look at the timed
evaluator on my website:

  http://needle.anest.ufl.edu/anest4/bills/Smalltalk.htm

It tries to synchronize the life of a modal progress dialog with a timed
task running in the background.  If you decide to try it, please let me know
how well it works.

Have a good one,

Bill

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

"Bill Schwab" <[hidden email]> wrote in message
news:9th60t$2l99i$[hidden email]...
> Dmitry,
>
> > I have a some monadic block myBlock with external libraries calls and I
> need
> > to limit an evaluation time by a some timeout. My code is:
>
> If the time is spent "in" the external calls, then you will have to
overlap
> them in order to get any benefit.  If you make a non-overlapped call to
> something that doesn't return, then you will find that Dolphin will hang
> until the call completes.  If you make "quick" calls to poll progress,
then
> you won't need to overlap.
>
> You might also need to take considerable care with exception handling in
> your (I'm assuming C++???) code to avoid problems should you terminate a
> call.  I'll defer to Blair on whether that's likely to be an issue, and if
> so, what you should do about it.

Dolphin terminates overlapped call threads very politely by raising an
exception in them when they explicitly do something interruptable. This
means that the external code is not interrupted in the middle of some
operation that needs to be atomic, and it is given a chance to clean up
(e.g. the destructors of C++ objects on the stack will be called). I imagine
Bill is thinking that TerminateThread() is called in response to
Process>>terminate when an overlapped call is outstanding, but although that
would be much simpler to implement it could result in resource leaks or
worse.

Regards

Blair

Blair,

> (e.g. the destructors of C++ objects on the stack will be called). I
imagine
> Bill is thinking that TerminateThread() is called in response to
> Process>>terminate when an overlapped call is outstanding, but although
that
> would be much simpler to implement it could result in resource leaks or
> worse.

Really, I wasn't thinking in that much detail.  My comment was based on what
we worked up as a likely cause for the socket connect timeout crash I was
experiencing.  However, that has some 16 bit thunking involved (in Win9x
Winsock), so maybe that's the difference?

Have a good one,

Bill

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