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.

--Hannes

On 9/20/17, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com> wrote:
> 2017-09-20 19:56 GMT+02:00 H. Hirzel <hannes.hirzel at gmail.com>:
>
>> On 9/20/17, H. Hirzel <hannes.hirzel at 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-Levente
> (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 at 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 at caesar.elte.hu>       Wed, Sep 20, 2017 at 6:44 PM
>> >> Reply-To: The general-purpose Squeak developers list
>> >> <squeak-dev at lists.squeakfoundation.org>
>> >> To: The general-purpose Squeak developers list
>> >> <squeak-dev at lists.squeakfoundation.org>
>> >> On Wed, 20 Sep 2017, H. Hirzel wrote:
>> >>
>> >>
>> >>     On 9/20/17, Levente Uzonyi <leves at caesar.elte.hu> wrote:
>> >>
>> >>         These methods were there to make it possible to migrate from
>> >> SharedQueue
>> >>         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.
>> >>
>> >
>>
>>
>>
>>
>