On 22.09.2017, at 12:19, H. Hirzel hannes.hirzel@gmail.com wrote:
Thanks, Nicolas for the additional information. I think as well that it might be the best just to benefit from the work done in Pharo.
I understand that you mean we should delete the class SharedQueue2 in the image and replace it with a file in from the SharedQueue class from Pharo 6 which is an updated version.
BTW there are six instances of SharedQueue in a recent image and zero instances of SharedQueue2 in a current image.
On the other side there is the question about the benefit of SharedQueue2 for Squeak. It seems that there were no complaints in the last 10 years about remaining with SharedQueue.
I needed a SQ for Squeaksource in 2014, but one that is compatible with a GemStone one. Essentially, I found the SharedQueue2 implementation more helpful but feared that names would change in the future, hence I copied the whole class…
Best regards -Tobias
--Hannes
On 9/20/17, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
2017-09-20 19:56 GMT+02:00 H. Hirzel hannes.hirzel@gmail.com:
On 9/20/17, H. Hirzel hannes.hirzel@gmail.com wrote:
The Pharo list has some notes about this in March 2011 and Levente was involved.
The issues are no longer accessible, e.g. https://code.google.com/archive/p/pharo/issues/3342
The pharo issue tracker has moved to fogbugz, but one needs to register for accessing... If you seek sharedQueue or SharedQueue you'll see a lot of activity
https://pharo.fogbugz.com/f/cases/3173/SharedQueue-ENH (was https://code.google.com/p/pharo/issues/detail?id=3125) issue opened for tracking changes in Squeak Igor claims its atomic-based queues are more robust under heavy-concurrent-load
https://pharo.fogbugz.com/f/cases/3390/have-a-look-at-sharedQueue-fixes-from... (was https://code.google.com/p/pharo/issues/detail?id=3342) issue opened for tracking changes in Squeak Markus said SharedQueue were replace with SharedQueue2 in Pharo It's not easy to find in which issue this was done exactly (the close status are unclear to me)
https://pharo.fogbugz.com/f/cases/3482/SharedQueue-Fixes (was https://code.google.com/p/pharo/issues/detail?id=3434) same kind as #3173
etc many other similar issues... and then:
https://pharo.fogbugz.com/f/cases/4073/Integrating-Atomics (was https://code.google.com/p/pharo/issues/detail?id=4026) tells that atomics was integrated in Pharo 3.0 originating from MCHttpRepository location: 'http://www.squeaksource.com/Atomics' user: '' password: ''
so maybe we can just pick current Pharo version along with tests and avoid more archeology
Nicolas
On 9/20/17, H. Hirzel hannes.hirzel@gmail.com wrote:
Just reposting the message http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-
September/195308.html
below so that it gets a proper subject line.
Note: SharedQueue and SharedQueue2 are both in the image. SharedQueue2 was included into Squeak version 3.9 by MarcusDenker (10-07-2005) for further testing.
Lex Spoon notes one year later that no problems have come to light. We should start migrating to this. All it requires is replacing SharedQueue by SharedQueue2.
Then two years later (12-17-2008) Keith_Hodges proposes a migration script
"fix begin" Installer mantis bug: 1375 fix: 'M1375-SharedQueue2Enable.1.cs'. WorldState initialize. EventSensor initialize. "fix end"
We need somebody to have a look at this script 'M1375-SharedQueue2Enable.1.cs' if it is still good to do the task.
BTW Pharo does not have two implementations of SharedQueue.
HH.
SharedQueue I provide synchronized communication of arbitrary objects between Processes. An object is sent by sending the message nextPut: and received by sending the message next. If no object has been sent when a next message is sent, the Process requesting the object will be suspended until one is sent.
SharedQueue2 An implementation of a shared queue based on class Monitor. Clients may may place items on the queue using nextPut: or remove them using methods like next or nextOrNil. Items are removed in first-in first-out (FIFO) order. It is safe for multiple threads to access the same shared queue, which is why this is a "shared" queue.
[monitor] is used to synchronize access from multiple threads.
[items] is an ordered collection holding the items that are in the queue. New items are added at the end, and old items are removed from the beginning.
All methods must hold the monitor while they run.
Levente Uzonyi leves@caesar.elte.hu Wed, Sep 20, 2017 at 6:44 PM Reply-To: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org On Wed, 20 Sep 2017, H. Hirzel wrote:
On 9/20/17, Levente Uzonyi leves@caesar.elte.hu wrote:
These methods were there to make it possible to migrate fromSharedQueue to SharedQueue2 in a live system.
Could you please give some more background information about this migration?
http://bugs.squeak.org/view.php?id=1375
That migration has not happened yet,Is there a reason not to do it after 5 years?
The mantis issue above has a few potential reasons. Another one may be that now there are other potential shared queue implementations to replace SharedQueue.