Event triggers, smart semaphores?

Peter Smet peter.smet at flinders.edu.au
Fri May 28 00:47:46 UTC 1999


Mark,

I just uploaded all the changes to 2.4b
using the 'update from server' command,
and saved the image, (I guess that makes it
equivalent to 2.4c).

I filed in my publish-subscribe change-set and
everything appears to be fine - 'PostOffice
start' begins testing in the background,
and all the messages appear on the Transcript...

When you got the error, were you working with
a clean image? Does the error occur with
2.4b or 2.4c?

One problem I have discovered is 'nested updates'.
That is, if one trigger sets off another trigger by one
of its subscribers, you will get a call to
PostOffice incoming: msg
from inside the PostOffice incoming: msg.
Since this method uses a mutex critical:
the two calls to the method will deadlock each other.

(The simple fix is to remove the protected: block from
PostOffice: incoming, which I have done)

I have found this to be a problem with OO and Semaphores
in general - there is so much cross-calling of messages it
is difficult to predict when a locked message will call itself.
It would be good to have a "smart semaphore" that forced
outside callers to wait, but let self invoke multiple invocations
of a message. I would appreciate it if someone could point
out some code to identify if the invoker of the currently
executing message is self or not.....

Does this idea of having outside callers wait in line, and
have self rudely pushing to the front of the queue make sense?

Any other solutions?


<irrelevant thought>

I just realized that you can use the event system to uphold all the
existing dependency relationships. Simply change
addDependent: aDependent (in Object) to read:
   self when: #changed
          send: #update
          to: aDependent.

plus its variant methods - you get the idea.....

</irrelevant thought>

Peter


>When I try "PostOffice start" I get an error about error: having the wrong
>number of parameters in WeakRegistry>>protected:  It's a hard error to find
>because (a) the error notifier shows up behind all other windows, since
>it's running in a background thread (restore the display to see the error
>notifier) and (b) the debugger for some reason doesn't show the backtrace
>if you choose to debug.
>
>But maybe this is on purpose?  I get a similar kind of error dialog when I
>send #run to the Transcript (playing with variations on Peter's examples).
>
>Mark
>
>--------------------------
>Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280
>(404) 894-5618 : Fax (404) 894-0673 : guzdial at cc.gatech.edu
>http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html
>
>
>





More information about the Squeak-dev mailing list