[Starkit] corruption of starkits by double access

[Steve Landers]

On 27/02/2006, at 7:32 PM, Jean-Claude Wippler wrote:

> Steve Landers wrote:
>
>> Steve Blinkhorn wrote:
>>
>>> How can I prevent write-enabled starkits from being corrupted by  
>>> being
>>> accessed a second time whilst already being accessed?   We are  
>>> seeing
>>> this as an occasional problem on Windows, where a user "loses" an  
>>> open
>>> window behind another application, and blithely double-clicks again.
>>>
>>> We can't find what sort of corruption is going on, because the  
>>> starkit
>>> then will not unwrap.
>>
>> This is a topic I'm also very interested in - for the very same  
>> reasons.
>>
>> From the reading I've done on the topic, cross-platform locking  
>> seems to be a minefield (or perhaps a cesspit - depending on your  
>> point of view).
>>
>> I'm wondering if the 80/20 solution might be to create a small  
>> Critcl extension that tries to create a Windows exclusive advisory  
>> lock on the kit / metakit file?
>>
>> Does anyone have an opinion on whether this is an approach worth  
>> investigating further?
>
> There's a page on this on the wiki - http://wiki.tcl.tk/593

Yes - I went through that in detail. Nothing quite worked.

> But if you drop x-platform, i.e. a plain Windows solution, then  
> it's probably all quite easy to solve.

That's my gut feeling too

> A lockfile opened in exclusive mode, or opening a socket on a fixed  
> port number (which one is the big Q!),

A lockfile has two problems - one is the extra file which (in some  
circumstances) is not ideal. The other is guaranteeing an atomic  
"check / create" operation when creating the lockfile. I haven't done  
it but I assume something using the open(n) command with the EXCL  
flag as discussed in this thread
http://groups.google.com/group/comp.lang.tcl/browse_frm/thread/ 
c45b0f6e727e157f/f038bfa590faaaa2?q=EXCL&rnum=1#f038bfa590faaaa2


A port number has the problem that it might trigger the windows  
firewall (no big deal, but could surprise end-users and require  
documentation).

> or perhaps actually solve the *real* problem: when launched again,  
> look for another instance and bring it to the front / exit if it  
> exists.

The situation I need to cope with isn't restricted to one user  
unfortunately. Steve's situation might be different.

> Much friendlier than exiting with some error.  Can a top-level  
> window be found by name on Windows?

Yes - TWAPI does it. Ffidl almost certainly will let you.  I'm not  
sure this approach guarantees uniqueness although I suspect you'd get  
a close approximation ;-)

Cheers

Steve