Smalltalk › Squeak › Squeak - Dev

#copyStack on Error

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Rob Withers

#copyStack on Error

Let's say I have a process which is consuming events off of a queue. I
don't want the process to ever terminate. If the handling of one of these
events results in an Error, even a Halt, this process will be opened in the
Debugger and the user could choose to abandon or terminate at will. Is it
possible to copyStack the activeProcess and open that stack in the Debugger
for the user. This way if the User terminates the process, it won't affect
the main process.

I wonder though, if the user resumes, will two proceses be consuming events
from the queue? Perhaps I can copyStack using copyTo: a specific context
that is above the point of consuming events, such that a resume will cause
the copied stack to go away.

Thanks for any assistance,
Rob

jgfoster

Re: #copyStack on Error

Rob Withers wrote:

> Let's say I have a process which is consuming events off of a queue.
> I don't want the process to ever terminate. If the handling of one of
> these events results in an Error, even a Halt, this process will be
> opened in the Debugger and the user could choose to abandon or
> terminate at will. Is it possible to copyStack the activeProcess and
> open that stack in the Debugger for the user. This way if the User
> terminates the process, it won't affect the main process.
>
> I wonder though, if the user resumes, will two proceses be consuming
> events from the queue? Perhaps I can copyStack using copyTo: a
> specific context that is above the point of consuming events, such
> that a resume will cause the copied stack to go away.
>
> Thanks for any assistance,
> Rob

One approach would be to have a "monitor" process that forks the "event
consumer" process. If the event consumer process terminates, the monitor
process would restart another one. The monitoring could be with a
semaphore that the event consumer signals in an unwind block. The
monitor process could also watch a flag to see if the event consumer
should be terminated or restarted.

James

Tony Garnock-Jones-2

Supervisors (was Re: #copyStack on Error)

James Foster wrote:
> One approach would be to have a "monitor" process that forks the "event
> consumer" process. If the event consumer process terminates, the monitor
> process would restart another one. The monitoring could be with a
> semaphore that the event consumer signals in an unwind block. The
> monitor process could also watch a flag to see if the event consumer
> should be terminated or restarted.

Erlang has a good approach here, with its notion of "supervisors":
http://www.erlang.org/doc/design_principles/sup_princ.html

Regards,
Tony
--
[][][] Tony Garnock-Jones | Mob: +44 (0)7905 974 211
[][] LShift Ltd | Tel: +44 (0)20 7729 7060
[] [] http://www.lshift.net/ | Email: [hidden email]

Rob Withers

Re: #copyStack on Error

In reply to this post by jgfoster

----- Original Message -----
From: "James Foster" <[hidden email]>
To: "The general-purpose Squeak developers list"
<[hidden email]>
Sent: Tuesday, October 30, 2007 9:29 AM
Subject: Re: #copyStack on Error

> Rob Withers wrote:
>> Let's say I have a process which is consuming events off of a queue. I
>> don't want the process to ever terminate. If the handling of one of
>> these events results in an Error, even a Halt, this process will be
>> opened in the Debugger and the user could choose to abandon or terminate
>> at will. Is it possible to copyStack the activeProcess and open that
>> stack in the Debugger for the user. This way if the User terminates the
>> process, it won't affect the main process.
>>
>> I wonder though, if the user resumes, will two proceses be consuming
>> events from the queue? Perhaps I can copyStack using copyTo: a specific
>> context that is above the point of consuming events, such that a resume
>> will cause the copied stack to go away.
>>
>> Thanks for any assistance,
>> Rob
> One approach would be to have a "monitor" process that forks the "event
> consumer" process. If the event consumer process terminates, the monitor
> process would restart another one. The monitoring could be with a
> semaphore that the event consumer signals in an unwind block. The monitor
> process could also watch a flag to see if the event consumer should be
> terminated or restarted.

This works and it avoids problems with copying stacks then trying to resume
them. Here is my processing loop:

processSends

[[pendingSends next value. true] whileTrue]
ifCurtailed: [self restart].

where restart first terminates the process (redundent perhaps), then starts
a new one. It works like a champ.

thanks,
Rob