[ENH] inter-process signaling (I stand corrected)

Andreas Raab andreas.raab at gmx.de
Sat Sep 20 12:45:38 UTC 2003


Oops - you're right, it doesn't return. Pretty nasty ;-)

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 4:11 AM
> To: The general-purpose Squeak developers list
> Subject: Re: [ENH] inter-process signaling (bad, bad, bad)
> 
> 
> You should have a look at #pvtSignal:list: (the method that actually 
> gets put onto the stack) ...that's the method that needs to 
> *not* return 
> (which would cause the stack to get fouled up)...and indeed, 
> that method 
> will never do a normal return (as the comment in that method 
> explains)...have a look and see what you think.  Point taken about 
> #lookupSelector:.
> 
> - Stephen
> 
> Andreas Raab wrote:
> 
> >>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
> >>>
> >>>
> >>>
> >>>      
> >>>
> >>    
> >>
> >
> >
> >  
> >
> 
> 
> 



More information about the Squeak-dev mailing list