Thanks Chris. I'll look into those. (Maybe the Ma Client Server could do with being mentioned more prominently among the Magma pages on the swiki - I missed it completely.)
Cheers, Nick
Chris Muller wrote:
Hi Nick, have a look at MagmaTestCase>>#testSequenceNumberGenerator, in the MagmaTester package. This demonstrates how to use MagmaCounter to synchronize a counter object between all clients.
By using a couple of Counters that index into a MagmaArray, you may implement a "MagmaQueue", that would be synchronized between all clients.
If you don't want the clients to have to poll the database for a piece of work, please also note the "Ma Client Server" framework is easy to use independently of Magma, and is pretty robust. Whoever is pushing the work onto the queue could simply send the work directly to another MagmaClient or send just a reference-id to the work-request in the database (have a look at #requiredProgress for making the latter work).
The MagmaTester uses "Ma Client Server", on its own, without Magma, to run its test-suite. By having a "conductor" image which simply sends out remotePerform:withArguments: to three other images (two clients and a server) to tell them to do various things for the test. See the swiki for more information on "Ma Client Server".
- Chris
I'm interested in using it to allow pieces of work (which I'll call 'jobs') to be handed out to one or more Squeak images ('workers').
On startup, each worker opens a connection to the Magma server, checks to see whether there are any jobs waiting to be done. If there are, the worker will take the first job off the queue, run it, and ultimately commit the result of the job back into Magma.
Other Magma clients are periodically going to push new jobs onto the end of the queue.
My first attempt just used an OrderedCollection to represent the queue, with one Magma client adding Arrays of numbers to it with #add: to simulate jobs being added; and another client removing them with #removeFirst; to simulate jobs being accepted by a worker.
This approach is prone to conflicts, presumably because each #add: or #removeFirst: is attempting to rewrite the entire internal state of the OrderedCollection.
So my question is, is there a better way of doing this? Use Magma to pass semaphores between clients? Or just live with the conflicts?
Thanks for any insight.
-Nick
Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma