file locking primitive

Julian Fitzell julian at beta4.com
Sat Jan 3 07:43:34 UTC 2004



Tim Rowledge wrote:
> Julian Fitzell <julian at beta4.com> wrote:
> 
> 
>>This has come up before but we need the file locking primitive in Squeak 
>>to support our work in OmniBase.  There has been enough interest in this 
>>in the past that I think it's worthwhile coming up with a primitive 
>>interface that is implementable in all the common VMs.
> 
> OK, first, I don't think that is possible. Just for one case RISC OS
> doesn't support locking of parts of a file. That may not worry you too
> much given the niche nature of RISC OS but it does point out the
> important aspect of platform portability - your code shouldn't cause
> trouble if a platform cannot support it.

Well, it certainly worries me in the sense that it needs to be 
considered if we're going to try for something cross-platform.

> So, take an extra few moments to think about the issue from this
> respect. You might also consider the possibility of providing a common
> Sq side api but a variety of platform side apis. We can do this fairly
> simply via platform specific VM plugins. I'd strongly recommend NOT
> adding this to the generic FilePlugin - for a start that particular vile
> monstrosity needs eviscerating with prejudice. It doesn't even have a
> decent way to find out if a file exists for goodness sake.

Ok... that's probably what I was thinking, I guess.  I definitely 
expected the primitive code to be different for each VM, though I didn't 
know yet whether they actually need to be different primitives.  You 
think it's better to have different primitives APIs rather than one that 
returns an error or something if you (for example) try to lock a byte 
range when that is not supported?  (obviously, in either case, code in 
Squeak would need to catch the problem and notify you, or just lock the 
whole file, or whatever the correct behaviour ends up being).

I don't really mind what people think is the correct solution - I'm 
happy to work out how to do it in whatever way is preferred - but I 
don't have enough background in the VM/plugin/primitive/portability 
areas to know what the best approach is.

Are we talking about different versions of the same primitive? 
Different primitives called conditionally by one plugin?  Different 
versions of the same plugin for each platform? Different plugins for 
each platform?

And do we want locking methods (in Squeak) that support locking byte 
ranges and error if it's not supported?  Or methods that fall back on 
locking the whole file?

Are there other differences besides byte range locking that will be 
problematic?

Basically, I need to implement something that works for us (work) next 
week.  If we (the list) can hammer out a consensus on what would also 
constitute a good start for others to use, I can do that on work time... 
but I need others to jump in and say what their ideal file locking 
methods/primitives would look like (at least a first pass at their ideals).

>>These questions are based mainly on ignorance about how Squeak deals 
>>with the file descriptors, etc.  Any pointers on how to get the FD from 
>>the primitive or comments on the correct interface for the primitive 
>>would be much appreciated.
> 
> You can't get a file descriptor as such; the file doohickey bytearray
> contains the structure specified in
> platforms/cross/plugins/fileplugin/fileplugin.h and you could read from
> that _in your  primitive_. Just include the .h file and away you go.
> Please don't try to extract it in Squeak. You shouldn't depend on such
> things. Apart from anything else maybe someday soon somebody will get
> annoyed enough to gut that foul fileplugin like a dawg and spread its
> entrails across the landscape in the manner it deserves.

Don't worry, I was definitely intending to get it in the primitive, not 
in Squeak. :)  When I said "from the primitive" I guess I meant "from 
within the primitive".

Julian

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




More information about the Squeak-dev mailing list