[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
|