file locking primitive

Julian Fitzell julian at beta4.com
Sun Jan 4 04:19:57 UTC 2004


Oh, so you were saying that on *nix you still use the primitive, but 
that *in addition* you need to keep an internal locking table to handle 
the case of the same process trying to lock the region again?

I think, as Tim says, it is essential that the Squeak interface behaves 
consistently across platforms even if the primitives don't.  What I 
think this means is that we need methods for fancier locking features 
that raise exceptions if they aren't supported on a given platform; and 
that we need to try to come up with some *consistent* level of support 
that we can say with fairly good confidence will work on most platforms.

This means:

- those who need fancy features but not platform-independence can write 
code that uses it, handle the exceptions appropriately, and be 
comfortable that the code will run everywhere it should and deal 
properly with environments where it won't work (maybe even falling back 
to a simpler locking mechanism if that makes sense for that code).

- those who just need *some* locking (whatever we consider our fairly 
safe subset - assuming we can find one) can use it without worrying 
about handling a whole bunch of extra error conditions and be 
comfortable it will just work in most cases

- when possible, we may able to use tricks (like an internal locking 
table) to implement one of our locking interfaces for a platform that 
wouldn't otherwise support it

Of course there's the additional problem of coming up with reasonably 
succinct names for the variations... how do you distinguish between the 
locking method that allows a process to lock a region more than once and 
the method that doesn't?  I've been told that if you can't name your 
method, you must not know what it does and therefore shouldn't write it 
yet - but I keep running into cases that I think disprove that... I know 
what it does, I just don't want a 200-character method name :)

Julian

David Gorisek wrote:

> Julian,
> 
> sorry for the misunderstanding. The point I was trying to make is that
> file locking behavior is different between OSs.
> 
> For example in VisualWorks the file locking primitive does not behave
> consistently between Linux and Windows version. Therefore OmniBase for
> VisualWorks (and for Smalltalk/X) keeps track of locks set on a file to
> prevent setting a lock twice (internally using a Dictionary).
> 
> So, if Squeak had a file locking primitive it would be nice if it
> behaved the same across various OSs.
> 
> Regards,
> 
> David Gorisek
> 
> 
> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On Behalf Of
> Julian Fitzell
> Sent: 3. januar 2004 21:12
> To: The general-purpose Squeak developers list
> Subject: Re: file locking primitive
> 
> 
> Hmm... Andrew seemed to be under the impression that the locking 
> currently didn't work at all on *nix (in the latest code you've given 
> us) and that adding a primitive was the correct action. If this already 
> works, we should be doing something else, or you're already doing it 
> then I would definitely like to know about it... :)
> 
> We do need to run the server on *nix, so what do you recommend?
> 
> Julian
> 
> David Gorisek wrote:
> 
> 
>>Regarding file locking primitives, there is also another issue that 
>>has to be taken into account.
>>
>>On Unix when the same process locks the same file region twice, the 
>>second call will succeed.
>>
>>On Windows the second call will fail, becuase the file region is 
>>already locked.
>>
>>For true interoperability the file locking behavior should be the same
> 
> 
>>across various OSs.
>>
>>OmniBase expects that file locking behavior is the same as on Windows.
> 
> 
>>Therefore for Unix systems OmniBase currently implements its own 
>>internal file locking table so that locking behavior of the 
>>ODBFileStream is the same as on Windows.
>>
>>Regards,
>>
>>David Gorisek
>>http://www.gorisek.com
>>
>>
> 
> 

-- 
julian at beta4.com
Beta4 Productions (http://www.beta4.com)




More information about the Squeak-dev mailing list