Asynchronous Messaging

Stephen Pair spair at advantive.com
Wed Jun 23 16:46:58 UTC 1999


I've posted an update to the asynchronous messages demo to:

http://www.advantive.com/squeak/ASync/ASyncMsg.23Jun1240pm.cs

I incorporated Marcel's trampoline concept (I modified Trampoline a bit to
better serve this specific scenario).  It helped to greatly clarify the
demos.

It's not linked from the front page yet.

- Stephen

> -----Original Message-----
> From: Stephen Pair [mailto:spair at advantive.com]
> Sent: Wednesday, June 23, 1999 9:54 AM
> To: marcel at system.de; squeak at cs.uiuc.edu
> Subject: RE: Asynchronous Messaging
>
>
> Marcel,
>
> > From: Marcel Weiher [mailto:marcel at system.de]
> >
> > Stephen,
> >
> >I've been eager to play with your code ever since you posted it, and
> >now that I finally had the chance I have to say it's absolutely
> >wonderful!
>
> Thanks!
>
> >Of course, one of the first things I did was add "Trampoline" support
> >so you can now use direct messaging syntax such as:
> >
> >jeff asend name:'Jeff Smith'.
> >instead of
> >jeff asend:#name: with:#('Jeff Smith').
>
> That's great...I hated the cumbersome way you had to send an asynchronous
> message before.  I hadn't thought of using your trampoline code...it
> certainly makes it a lot nicer.
>
> >However, I am having problems with parts of the code, especially with
> >#send: sometimes being implemented as a straight #asend: (and
> >potentially deadlocking if not), the mysterious #answer:
> >implementation (what is at:3 ? -- it fails with some of my mods) etc.
> >
> >Maybe you could explain your code a little?
>
> Sure...
>
> ----
> ContextPart>>answer: obj
> 	^(self sender at: 3) nextPut: obj.
> ----
>
> What I did here was make an assumption about the
> sender...particularly that
> the sender has the answer queue as an argument...this is a hack I used to
> avoid having to alter ContextPart to have a slot for the answer queue (I
> think I crashed Squeak a couple of time trying).  Thus, the caller to a
> method that uses #answer: must have an answer queue as one of it's
> arguement.  Any of the #asend variants do this for you.
>
> As far as deadlocking is concerned, I thought the only way you could
> encounter that was through an #aqsend (asynchronous queued send).  For
> example, you do an #aqsend and in turn that method causes another
> #aqsend to
> the same object.  I wasn't too concerned with trying to eliminate all
> deadlocking scenarios (I'm not even sure you can).
>
> I could see a lot of scenarios where this stuff would be really useful.
>
> - Stephen
>
> P.S.  It seems like the change set doesn't file in correctly with 2.4c
> anymore...did you notice that?
>
>





More information about the Squeak-dev mailing list