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
|