The problem, or at least one of them, is the test. PostOffice class>>testAll
is almost entirely dominated by #test4 which, in turn, is almost entirely
dominated by 500 iterations of registering an event with very few triggers
done. Since registering events is much the same whether done pub-evt-sub or
pub-sub-evt, I wouldn't expect much change. The real world, I suspect, is
more likely to be one register and numerous triggers. This may well run
faster in the pub-evt-sub order.


You're absolutely right -it was just a quick and dirty experiment.

>
>The other thing I am finding is that the garbage
>collection works brilliantly with newly created
>unreferenced objects, but Browser windows,
>Prompt windows, Morphic projects etc all hang
>around even after their windows have been closed.
>'Smalltalk garbageCollect' does not remove these
>guys either. Why are they not garbage - how long
>are these closed windows meant to hang around?
>
>If you go to a higher level window and delete the
>project windows only then do things seem to get
>collected.

I took a look and found a few hanging around in a clean system. The Morphic
tabs hold instances of some of the more common window/browser types, so that
could be part of it. Other than that, can you describe a *simple* test that
shows what you are seeing?


Open an inspector on PostOffice default, look at how many objects are
registered. Open a few morpic windows. Open a transcript or two.
Close a transcript. open and close a few browsers and inspectors.
Do a few FillInTheBlank forms. Then dismiss all of these windows
by clicking the close button in their top left corner. Inspect the
PostOffice again. Do a Smalltalk garbageCollect. Keep
inspecting. What I am finding is that none of these references
are disappearing - Even when i have ripped out the
DependentFields global. Something is hanging on to these
references, but I dont know what....

I think now that this problem can't be poor finalization by
PostOffice, since there are no nil values lying around in
the WKDictionary - the gc is simply not getting these refs..


>Well, say there are two virtual machines, connected via the
>internet. MachineA has an object called 'Harry' that subscribes
>to event #callMe from publisher 'Sally' on MachineB.
>on MachineB, 'Sally' now triggers: #callMe. The challenge is
>for the PostOffice to get the message to 'Harry'.
>I think we need a ProxyObject class on machineB, that
>stands in for 'Harry' and forwards the events to him.

Ah... I think the problem will be mostly solved when objects can send
ordinary messages to objects on other machines/images. Once that happens,
your code (which just sends messages) should port fairly easily.

----
Yes - distributed events is just an extension of RMI. I am wallowing in some
ORB code
now. I can get two objects at either end of a socket connection talking, by
one sending
selector Symbols and the other turning all return values into string
representations.

The tricky bit for me is serializing objects. The ORB I downloaded uses
7 bit bytes to do this, and I can't figure out why they aren't just bytes...
It seems to me that streaming objects to disk should be identical to
streaming them over the net, but unfortunately this does not seem to
be the case. Anybody had experience serializing objects across
network connections?

Peter