Re: threading of FileSet

Vitezslav Stejskal wrote:
> 
> 
> Svata Dedic wrote:
> 
>> Jesse Glick wrote:
>>
>>> Svatopluk Dedic wrote:
>>>
>>> Re. passing a Mutex to the FileSet constructor - perhaps keep it 
>>> simple, and just define one public static final Mutex MUTEX to be 
>>> used with *any* fileset. Simple and should work. You can just fire 
>>> changes 
>>
>>
>>
>> OK - my use case was to postpone events fired from several tightly 
>> coupled filesets. Blocking events from all FileSets includes this 
>> scenario naturally.
> 
> 
> Oh, I am sorry if I misunderstood you Svata, but I thing your original 
> requirement was to postpone events firing when you are in the sync. 
> section holding your internal lock used for syncing your internal 
> structures. This is generic problem not tied to FileSets. Any class 
> which fires events should allow to postpone events firing per clients 
> request otherwise clients must not touch mutators of this class when 
> holding some lock.
> 
As you wrote, calling some event-firing method while holding a lock is a 
more general problem. However if the client locks a Mutex, prior to the 
call, which is used to front outgoing events in a queue within FileSet 
implementation, the client can postpone events from being fired until 
after the Mutex is released, which may be several FSet operations (also 
firing events) ahead.

So if some foreign client asks the FileSet, it observes the modified 
state. But it is not woken up prematurely by getting an event at the 
mid-point.

> I am sorry, but I don't see how single global FileSet's Mutex can help 
> with this. Or do you mean that every client using FileSets API should 
> also use this mutex to synchronize its internal structures? IMO this 

Not for syncing access to structures (as my original suggestion is 
concerned), only for firing events - that's much how the runAtomicAction 
in filesystems work. Unlike runAtomicAction, having several fsets using 
the same Mutex instance effectively serialize their outgoing events.

> isn't doable in every situation. This solution would lead to one super 
> Mutex used everywhere in the Netbeans or (which seems better alternative 
> to me) to make Netbeans singlethreaded.
Such filesets-global Mutex would only apply to filesets operation, not 
to all operations in NetBeans.

-Svata