Shaping, (or should I call you bigfoot :-)
That's interesting, because the initialize method has no critical sections.
Before you set the default variable to nil, it is a good idea to remove it from WeakArray: WeakArray removeWeakDependent: self default. default := nil. (assuming this is a class method). I have just added a reset method that does this...
I am glad you pointed this out, since Singletons should not really have a #new method for clients to call. I have fixed this by letting PostOffice control all instance creation, and disabling PostOffice new.
re Subscribers building up. I have noticed this only when the FinalizationProcess has come to a halt or been interupted. Check this by inspecting WeakArray FinalizationProcess. In the normal test, there should be hundreds of fluctuating nils in the publishers array - this is normal.....
PS my latest version did not have a reset method. Are you using an earlier version? Or did you add the method? PostOffice is now subclassed from Object rather than WeakRegistry - this seemed to fix some synchronization problems.
I have attached the most recent version, which I really hope will fix these concurrency issues....
PostOffice now uses Bob Arning's RecursiveSemaphore, (thanks very much for this Bob) and the tests are all running well. This semaphore is better than the one I hacked together, since it implements signal and wait, and can so be substituted transparently for a normal Semaphore. My Semaphore only implemented critical (both implementations seemed to work fine).
On the weekend, I had the PostOffice duplicating all the changed update: protocol by changing addDependent: to route the messages appropriately. It didnt crash during that.
I think the next step in making things more robust is to use Tim's exceptions to ensure all semaphores stay in a consistent state, no matter how they are broken out of. (something like valueNowOrOnUnwindDo).
PS Please also test things on a clean image to see if the errors remain.
Peter
Regarding your latest: if you reset PostOffice's default variable to nil (using a #reset method), and then evaluate PostOffice>>new, the system
locks
up in the critical section during PO initialize. Any ideas? Also, I've have seen in the previous version odd finalization behvior in which subscribers started to build up, and could only be finalized by saving, quiting and restarting the image.
Shaping
Content-Type: application/octet-stream; name="Publish-Subscribe.1June1009am.cs" Content-Disposition: attachment; filename="Publish-Subscribe.1June1009am.cs"
Attachment converted: Anon:Publish-Subscribe.1June1009am.c (????/----) (0000A84A)
squeak-dev@lists.squeakfoundation.org