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
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
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
----- Original Message ----- From: "James Foster" Smalltalk@JGFoster.net To: "The general-purpose Squeak developers list" squeak-dev@lists.squeakfoundation.org 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
squeak-dev@lists.squeakfoundation.org