Migrating from SharedQueue to SharedQueue2? (Mantis http://bugs.squeak.org/view.ph
Locked
Migrating from SharedQueue to SharedQueue2? (Mantis http://bugs.squeak.org/view.ph
 
|
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. |
Re: Migrating from SharedQueue to SharedQueue2? (Mantis http://bugs.squeak.org/view.ph
|
|
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. > |
Re: Migrating from SharedQueue to SharedQueue2? (Mantis http://bugs.squeak.org/view.ph
|
|
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 |
Re: Migrating from SharedQueue to SharedQueue2? (Mantis http://bugs.squeak.org/view.ph
|
|
2017-09-20 19:56 GMT+02:00 H. Hirzel <[hidden email]>:
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 so maybe we can just pick current Pharo version along with tests and avoid more archeology Nicolas
|
Re: Migrating from SharedQueue to SharedQueue2? (Mantis http://bugs.squeak.org/view.ph
|
|
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. >> >> >> > >> >> >> >> > |
Re: Migrating from SharedQueue to SharedQueue2? (Mantis http://bugs.squeak.org/view.ph
|
|
> 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. >>>>> >>>> >>> >>> >>> >>> >> > |
Re: Migrating from SharedQueue to SharedQueue2? (Mantis http://bugs.squeak.org/view.ph
|
|
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. >>>>>> >>>>> >>>> >>>> >>>> >>>> >>> >> > > > |
Re: Migrating from SharedQueue to SharedQueue2? (Mantis http://bugs.squeak.org/view.ph
|
|
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. >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >> >> >> > |
Re: Migrating from SharedQueue to SharedQueue2? (Mantis http://bugs.squeak.org/view.ph
|
|
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. |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |