Migrating from SharedQueue to SharedQueue2? (Mantis http://bugs.squeak.org/view.php?id=1375)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Migrating from SharedQueue to SharedQueue2? (Mantis http://bugs.squeak.org/view.php?id=1375)

Hannes Hirzel
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
<[hidden email]> Wed, Sep 20, 2017 at 6:44 PM
Reply-To: The general-purpose Squeak developers list
<[hidden email]>
To: The general-purpose Squeak developers list
<[hidden email]>
On Wed, 20 Sep 2017, H. Hirzel wrote:


    On 9/20/17, Levente Uzonyi <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: Migrating from SharedQueue to SharedQueue2? (Mantis http://bugs.squeak.org/view.php?id=1375)

Hannes Hirzel
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

On 9/20/17, H. Hirzel <[hidden email]> 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
> <[hidden email]> Wed, Sep 20, 2017 at 6:44 PM
> Reply-To: The general-purpose Squeak developers list
> <[hidden email]>
> To: The general-purpose Squeak developers list
> <[hidden email]>
> On Wed, 20 Sep 2017, H. Hirzel wrote:
>
>
>     On 9/20/17, Levente Uzonyi <[hidden email]> 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.
>

Reply | Threaded
Open this post in threaded view
|

Re: Migrating from SharedQueue to SharedQueue2? (Mantis http://bugs.squeak.org/view.php?id=1375)

Hannes Hirzel
On 9/20/17, H. Hirzel <[hidden email]> 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
>
> On 9/20/17, H. Hirzel <[hidden email]> 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
>> <[hidden email]> Wed, Sep 20, 2017 at 6:44 PM
>> Reply-To: The general-purpose Squeak developers list
>> <[hidden email]>
>> To: The general-purpose Squeak developers list
>> <[hidden email]>
>> On Wed, 20 Sep 2017, H. Hirzel wrote:
>>
>>
>>     On 9/20/17, Levente Uzonyi <[hidden email]> 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.
>>
>



Users of SharedQueue_21.png (81K) Download Attachment
Users of SharedQueue2_3.png (40K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Migrating from SharedQueue to SharedQueue2? (Mantis http://bugs.squeak.org/view.php?id=1375)

Nicolas Cellier


2017-09-20 19:56 GMT+02:00 H. Hirzel <[hidden email]>:
On 9/20/17, H. Hirzel <[hidden email]> 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

issue opened for tracking changes in Squeak
Igor claims its atomic-based queues are more robust under heavy-concurrent-load

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)

same kind as #3173

etc many other similar issues... and then:

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 <[hidden email]> 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
>> <[hidden email]>       Wed, Sep 20, 2017 at 6:44 PM
>> Reply-To: The general-purpose Squeak developers list
>> <[hidden email]>
>> To: The general-purpose Squeak developers list
>> <[hidden email]>
>> On Wed, 20 Sep 2017, H. Hirzel wrote:
>>
>>
>>     On 9/20/17, Levente Uzonyi <[hidden email]> 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.
>>
>






Reply | Threaded
Open this post in threaded view
|

Re: Migrating from SharedQueue to SharedQueue2? (Mantis http://bugs.squeak.org/view.php?id=1375)

Hannes Hirzel
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 <[hidden email]> wrote:

> 2017-09-20 19:56 GMT+02:00 H. Hirzel <[hidden email]>:
>
>> On 9/20/17, H. Hirzel <[hidden email]> 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 <[hidden email]> 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
>> >> <[hidden email]>       Wed, Sep 20, 2017 at 6:44 PM
>> >> Reply-To: The general-purpose Squeak developers list
>> >> <[hidden email]>
>> >> To: The general-purpose Squeak developers list
>> >> <[hidden email]>
>> >> On Wed, 20 Sep 2017, H. Hirzel wrote:
>> >>
>> >>
>> >>     On 9/20/17, Levente Uzonyi <[hidden email]> 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.
>> >>
>> >
>>
>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Migrating from SharedQueue to SharedQueue2? (Mantis http://bugs.squeak.org/view.php?id=1375)

Tobias Pape

> On 22.09.2017, at 12:19, H. Hirzel <[hidden email]> 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 <[hidden email]> wrote:
>> 2017-09-20 19:56 GMT+02:00 H. Hirzel <[hidden email]>:
>>
>>> On 9/20/17, H. Hirzel <[hidden email]> 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 <[hidden email]> 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
>>>>> <[hidden email]>       Wed, Sep 20, 2017 at 6:44 PM
>>>>> Reply-To: The general-purpose Squeak developers list
>>>>> <[hidden email]>
>>>>> To: The general-purpose Squeak developers list
>>>>> <[hidden email]>
>>>>> On Wed, 20 Sep 2017, H. Hirzel wrote:
>>>>>
>>>>>
>>>>>    On 9/20/17, Levente Uzonyi <[hidden email]> 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.
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: Migrating from SharedQueue to SharedQueue2? (Mantis http://bugs.squeak.org/view.php?id=1375)

Hannes Hirzel
On 9/22/17, Tobias Pape <[hidden email]> wrote:

>
>> On 22.09.2017, at 12:19, H. Hirzel <[hidden email]> 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…

OK, where did you get the copy of SharedQueue2 from?
Compatibility with other Smalltalk dialects such as GemStone, Pharo is
an issue of course. I do not know about Cuis.


>
> Best regards
> -Tobias
>>
>> --Hannes
>>
>> On 9/20/17, Nicolas Cellier <[hidden email]> wrote:
>>> 2017-09-20 19:56 GMT+02:00 H. Hirzel <[hidden email]>:
>>>
>>>> On 9/20/17, H. Hirzel <[hidden email]> 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 <[hidden email]> 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
>>>>>> <[hidden email]>       Wed, Sep 20, 2017 at 6:44 PM
>>>>>> Reply-To: The general-purpose Squeak developers list
>>>>>> <[hidden email]>
>>>>>> To: The general-purpose Squeak developers list
>>>>>> <[hidden email]>
>>>>>> On Wed, 20 Sep 2017, H. Hirzel wrote:
>>>>>>
>>>>>>
>>>>>>    On 9/20/17, Levente Uzonyi <[hidden email]> 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.
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Migrating from SharedQueue to SharedQueue2? (Mantis http://bugs.squeak.org/view.php?id=1375)

Hannes Hirzel
Tobias,

The SharedQueue2 class comment: time stamp is 25th June 2005; author ls.


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.

-----------------------------------
Other time stamps
'From Squeak6.0alpha of 18 September 2017 [latest update: #17390] on
22 September 2017 at 12:43:13 pm'!
!SharedQueue2 methodsFor: 'accessing' stamp: 'ul 10/15/2010 08:24'!
!SharedQueue2 methodsFor: 'accessing' stamp: 'ls 6/25/2005 14:00'!
!SharedQueue2 methodsFor: 'accessing' stamp: 'nice 12/26/2009 21:34'!
!SharedQueue2 methodsFor: 'accessing' stamp: 'ul 10/15/2010 08:23'!
!SharedQueue2 methodsFor: 'accessing' stamp: 'ls 6/25/2005 14:00'!
!SharedQueue2 methodsFor: 'accessing' stamp: 'ul 10/15/2010 08:23'!
!SharedQueue2 methodsFor: 'accessing' stamp: 'ls 6/25/2005 14:01'!
!SharedQueue2 methodsFor: 'initializing' stamp: 'ls 6/25/2005 13:48'!
!SharedQueue2 methodsFor: 'printing' stamp: 'ls 6/25/2005 13:56'!
!SharedQueue2 methodsFor: 'size' stamp: 'ls 6/25/2005 14:03'!
!SharedQueue2 methodsFor: 'size' stamp: 'ls 6/25/2005 14:04'!
!SharedQueue2 methodsFor: '*39Deprecated' stamp: 'ls 6/25/2005 14:07'!
!SharedQueue2 methodsFor: '*39Deprecated' stamp: 'ls 6/25/2005 14:02'!
!SharedQueue2 methodsFor: 'copying' stamp: 'nice 10/5/2009 19:07'!
!SharedQueue2 class methodsFor: 'instance creation' stamp: 'ls 6/25/2005 13:53'!



On 9/22/17, H. Hirzel <[hidden email]> wrote:

> On 9/22/17, Tobias Pape <[hidden email]> wrote:
>>
>>> On 22.09.2017, at 12:19, H. Hirzel <[hidden email]> 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…
>
> OK, where did you get the copy of SharedQueue2 from?
> Compatibility with other Smalltalk dialects such as GemStone, Pharo is
> an issue of course. I do not know about Cuis.
>
>
>>
>> Best regards
>> -Tobias
>>>
>>> --Hannes
>>>
>>> On 9/20/17, Nicolas Cellier <[hidden email]> wrote:
>>>> 2017-09-20 19:56 GMT+02:00 H. Hirzel <[hidden email]>:
>>>>
>>>>> On 9/20/17, H. Hirzel <[hidden email]> 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 <[hidden email]> 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
>>>>>>> <[hidden email]>       Wed, Sep 20, 2017 at 6:44 PM
>>>>>>> Reply-To: The general-purpose Squeak developers list
>>>>>>> <[hidden email]>
>>>>>>> To: The general-purpose Squeak developers list
>>>>>>> <[hidden email]>
>>>>>>> On Wed, 20 Sep 2017, H. Hirzel wrote:
>>>>>>>
>>>>>>>
>>>>>>>    On 9/20/17, Levente Uzonyi <[hidden email]> 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.
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Migrating from SharedQueue to SharedQueue2? (Mantis http://bugs.squeak.org/view.php?id=1375)

Tobias Pape
In reply to this post by Hannes Hirzel

> On 22.09.2017, at 12:37, H. Hirzel <[hidden email]> wrote:
>
> On 9/22/17, Tobias Pape <[hidden email]> wrote:
>>
>>> On 22.09.2017, at 12:19, H. Hirzel <[hidden email]> 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…
>
> OK, where did you get the copy of SharedQueue2 from?

It was in my squeak image (4.3 or so at that time i think)


> Compatibility with other Smalltalk dialects such as GemStone, Pharo is
> an issue of course. I do not know about Cuis.
>
>
>>
>> Best regards
>> -Tobias
>>>
>>> --Hannes
>>>
>>> On 9/20/17, Nicolas Cellier <[hidden email]> wrote:
>>>> 2017-09-20 19:56 GMT+02:00 H. Hirzel <[hidden email]>:
>>>>
>>>>> On 9/20/17, H. Hirzel <[hidden email]> 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 <[hidden email]> 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
>>>>>>> <[hidden email]>       Wed, Sep 20, 2017 at 6:44 PM
>>>>>>> Reply-To: The general-purpose Squeak developers list
>>>>>>> <[hidden email]>
>>>>>>> To: The general-purpose Squeak developers list
>>>>>>> <[hidden email]>
>>>>>>> On Wed, 20 Sep 2017, H. Hirzel wrote:
>>>>>>>
>>>>>>>
>>>>>>>   On 9/20/17, Levente Uzonyi <[hidden email]> 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.