Preventing process termination inside #ensure: block

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Preventing process termination inside #ensure: block

David Gorisek-5
Hi All,

does anyone know how to prevent process termination when it's running inside
#ensure: block.

For instance if I try this example:

---
p := [[(Delay forSeconds: 1) wait]
           ensure: [
             Transcript nextPutAll: 'Inside ensure'; cr.
             (Delay forSeconds: 5) wait.
             Transcript nextPutAll: 'Done ensure'; cr]]
                      forkAt: Processor userBackgroundPriority.

(Delay forSeconds: 3) wait.
p terminate.
---

It will show that process will be terminated inside the #ensure: block.
However, when I terminate the process while it is not in the #ensure block
yet, the #ensure: block will be executed and completed as expected.

So, I would need a method e.g. #safeTerminate which will wait until the
ensure block terminates before terminating the process.

So for example:

  A ensure: B

it should terminate only A, but if inside B it should not terminate the
process but wait until completed.

And for example:

  A ensure: [B ensure: C]

It should terminate A, or B, but not C.

Is there a way to do this in Dolphin? I need this for a server watchdog
which terminates threads that run too long.

Thank you in advance,

David Gorisek


Reply | Threaded
Open this post in threaded view
|

Re: Preventing process termination inside #ensure: block

Dmitry Zamotkin-5
Hi David,

Here is a dirty solution:

p := [ [(Delay forSeconds: 1) wait] ensure: [
    ensureProcess := [
        Transcript nextPutAll: 'Inside ensure'; cr.
        (Delay forSeconds: 5) wait.
        Transcript nextPutAll: 'Done ensure'; cr] fork
    ]
] forkAt: Processor userBackgroundPriority.

(Delay forSeconds: 3) wait.
p terminate.

SessionManager inputState loopWhile: [ ensureProcess isDead not ].
Transcript nextPutAll: 'Ensure block is dead'; flush.

--
Dmitry Zamotkin


Reply | Threaded
Open this post in threaded view
|

Re: Preventing process termination inside #ensure: block

David Gorisek-5
This is no solution to us. We need something that would work without
changing any of the existing code.

Thanks,

David


"Dmitry Zamotkin" <[hidden email]> wrote in message
news:c5omvp$qis$[hidden email]...

> Hi David,
>
> Here is a dirty solution:
>
> p := [ [(Delay forSeconds: 1) wait] ensure: [
>     ensureProcess := [
>         Transcript nextPutAll: 'Inside ensure'; cr.
>         (Delay forSeconds: 5) wait.
>         Transcript nextPutAll: 'Done ensure'; cr] fork
>     ]
> ] forkAt: Processor userBackgroundPriority.
>
> (Delay forSeconds: 3) wait.
> p terminate.
>
> SessionManager inputState loopWhile: [ ensureProcess isDead not ].
> Transcript nextPutAll: 'Ensure block is dead'; flush.
>
> --
> Dmitry Zamotkin
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Preventing process termination inside #ensure: block

Bill Schwab-2
In reply to this post by David Gorisek-5
David,

> Is there a way to do this in Dolphin? I need this for a server watchdog
> which terminates threads that run too long.

Take a look at my timed evaluators; if they don't do the job, please let me
know why - it might be important to me too =:0

Have a good one,

Bill

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


Reply | Threaded
Open this post in threaded view
|

Re: Preventing process termination inside #ensure: block

Chris Uppal-3
In reply to this post by David Gorisek-5
David Gorisek wrote:

> This is no solution to us. We need something that would work without
> changing any of the existing code.

I suppose you /could/ do runtime reflection on the stack to see if an #ensure:
block is executing in the target Process and (somehow) wait until that has
finished before interrupting.  That might be fun to code (though it lies well
beyond /my/ skill), but I don't really think it'd be practical.

If not then you are just going to have to accept that your design is unworkable
and change it.  In fact it /sounds/ unworkable right from the outset -- you
have two threads affecting the state of a computation with no Mutex (or
similar) protection between them.

    -- chris