So Set>>do: is not thread-safe. That's an interesting point. I think it would really improve the quality of the present API if all standard containers would be thread-safe. Is there already a project that tries to achieve this?

Ciao,
Marcel

-----Ursprüngliche Nachricht-----
Von: squeak-dev-bounces at lists.squeakfoundation.org [mailto:squeak-dev-bounces at lists.squeakfoundation.org] Im Auftrag von Andreas Raab
Gesendet: Samstag, 16. Oktober 2010 07:38
An: The general-purpose Squeak developers list
Betreff: [squeak-dev] Re: Example of non-concurrent code :)

On 10/15/2010 10:16 PM, Igor Stasenko wrote:
> On 16 October 2010 08:00, Andreas Raab<andreas.raab at gmx.de>  wrote:
>> On 10/15/2010 9:41 PM, Igor Stasenko wrote:
>>>
>>> Here, the bug:
>>> first it sends #peekEvent and its not nil.
>>> Okay, then after some logic voodo, it sends nextEvent, without
>>> precaution, that it may also answer nil!
>>>
>>> So, if some other process get between these two sends (*a*, *b*) and
>>> fetch/flush all events, a code will fail,
>>
>> But there is no such code. The method in question is run from within Morphic
>> so unless there is a concurrent thread which for some reason flushes the
>> event queue[*1], this case simply cannot happen. The shared queue used for
>> synchronization here is specifically for synchronizing the event queue with
>> the Morphic event loop. It's not for general purpose
>> let's-just-dump-all-events-at-random-points-in-time usage.
>>
>> [*1] I would claim that such code itself buggy. Flushing the event queue
>> should be synchronized with Morphic.
>
> There are 209 references to Sensor in my image.
> How i can be sure that every place does not using it outside a Morphic
> UI process?

You can be just as sure as arguing that Set>>do: isn't thread safe. How 
can you be sure that every place does not use it in a separate thread? 
This kind of argument is pointless. If you have evidence that this is 
indeed a problem, then let's fix it (rather: let's fix the place that 
accesses UI stuff from another thread). But let's not pick a random 
method in the image and go all wild about that it might perhaps not be 
thread safe.

Cheers,
   - Andreas