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

H. Hirzel hannes.hirzel at gmail.com
Wed Sep 20 17:56:53 UTC 2017


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
>
> 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.
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Users of SharedQueue_21.png
Type: image/png
Size: 60852 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20170920/835e4042/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Users of SharedQueue2_3.png
Type: image/png
Size: 30428 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20170920/835e4042/attachment-0003.png>


More information about the Squeak-dev mailing list