>From the code:

	suspendedContext := MethodContext
		sender: suspendedContext
		receiver: self
		method: (self class methodDict at: #pvtSignal:list:)
		arguments: (Array with: anException with: myList).

This won't work. Upon return from the context an extra value will be pushed
on the stack screwing up the sender's stack quite thoroughly. No big deal if
the sender returns immediately without the use of the value but in the
"interesting" situations it will either continue to compute using the return
value from the intermediate context or (in the worst case) overflow its
stack frame and crash Squeak.

And in addition you should really use #lookupSelector: instead of "self
class methodDict at:" - this wouldn't work for Process subclasses at all.

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of Stephen Pair
> Sent: Saturday, September 20, 2003 1:04 AM
> To: The general-purpose Squeak developers list
> Subject: [ENH] inter-process signaling
> 
> 
> The attached file-out is an improved inter-process signaling 
> mechanism.  
> It adds a method #signal: to Process that accepts an exception as its 
> argument.  It will signal the exception in the context of the 
> receiver.  
> If the receiver is currently suspended (i.e. not on a list), the 
> exception will not get signaled until the process is resumed.  If the 
> receiver is currently blocking on a Semaphore, this method 
> will return 
> the receiver to a non-blocked state and the process will 
> resume with the 
> exception being signaled.  If that exception is handled and 
> resumed, the 
> process will return to a blocked state if the semaphore does not have 
> any excess signals.
> 
> So, as Ned pointed out, you could use this to timeout a 
> process that is 
> waiting on a Semaphore with an exception.  It might look 
> something like 
> this.
> 
>   | sem proc |
>   sem := Semaphore new.
>   proc := [sem wait] newProcess.
>   proc resume.
>   (Delay forSeconds: 5) wait.
>   proc signal: (Error new messageText: 'hey wake up!'; yourself).
> 
> I think this has the potential for a multitude of uses.  I 
> can imagine 
> extending the process browser such that you can right click 
> and send a 
> variety of common signals to a process.
> 
> - Stephen
> 
> Stephen Pair wrote:
> 
> > Ned Konz wrote:
> >
> >> On Friday 19 September 2003 11:56 am, Stephen Pair wrote:
> >>  
> >>
> >>> One of the things that crossed my mind not too long ago is that it
> >>> would be nice if we could signal exceptions in another 
> process. For 
> >>> example:
> >>>
> >>>  Error new messageText: 'some error message'; signalProcess:
> >>> someProcess
> >>>
> >>> Or,
> >>>
> >>>  someProcess signal: (Error new messageText: 'some error message';
> >>> yourself)
> >>>
> >>> This could be useful for graceful termination of processes (among
> >>> many other things)...unwind actions could always happen in the
> >>> process where they were defined.  The default action of a 
> Terminate
> >>> exception would be to terminate the active process.  Here's the
> >>> method that seems to do the trick:
> >>>
> >>> Process>>signal: anException
> >>>
> >>>    Processor activeProcess == self ifTrue: [^anException signal].
> >>>    suspendedContext := MethodContext
> >>>        sender: suspendedContext
> >>>        receiver: self
> >>>        method: thisContext method
> >>>        arguments: (Array with: anException).
> >>>
> >>>   
> >>
> >>
> >> Thanks!
> >>
> >> I've asked for this several times and no one has come up 
> with it yet.
> >>
> >> One obvious use of this is to provide Semaphore>>wait methods that 
> >> raise an exception on a timeout.
> >>
> >
> > Of course, if your process happens to be waiting on a Semaphore, 
> > sending #signal: to the process will not wake it up (nothing will 
> > happen until the semaphore gets signaled)...you could add a line to 
> > the end of that method to suspend and resume (ie.  "self suspend; 
> > resume") and that will wake it up...but, what I'd really 
> like is a way 
> > of waking it up to process the exception and when you resume the 
> > exception have the process go back into a state where it's still 
> > waiting on the original semaphore (if it hadn't been 
> signaled in the 
> > interim).  I had a solution for that, but it seems to have 
> a tendency 
> > to crash the VM.  ;)
> >
> > - Stephen
> >
> >
> >
> 
>