fcntl semantics

[Donn Cave]

Quoth buzmeg at newsguy.com:
| In article <9rsldh$26fe$1 at nntp6.u.washington.edu>, Donn says...
|> Quoth buzmeg at newsguy.com:
|> Are you really talking about fcntl()?  The only struct parameter that
|> I can think of for fcntl() is struct flock, and fcntlmodule already
|> provides a lockf function that wraps that.
|
| Point taken, but lockf doesn't strictly wrap the fcntl flock structure.  pid i
| missing for starters (I'm checking to see how much I use it and if I can get
| around it).  Some systems include a sysid field.  This kind of variation is
| easily wrapped with dicts.
|
| The struct is there and if I need to get at it, I have to go through creating 
| machine/compiler/OS specific packed struct in my Python code to do so.  That i
| counterproductive, when, as you point out, lockf already *has* most of the cod
| to do the appropriate mapping.
|
|> In general, I would expect lockf to be the model for packed structs.
|> When there's enough call for a particular ioctl that it's worth building
|> support for the struct into fcntmodule, then it will end up with its
|> own function entry point, and typically the input would be a tuple.
|> If you try to write a generic ioctl for all structs, with a dictionary
|> input like you describe, I think you'll see that it doesn't get you
|> much more than that.
|
| Actually, I would argue against that quite strongly.  As I said, lockf does
| *NOT* map correctly for all the members of the flock struct.  A dictionary
| mapping avoids the issues of system specific struct members.  You can use them
| or not.  A tuple does not.  Where does pid go, for instance?  At the end, at t
| beginning, in the middle?  How about sysid?  How many members in the tuple? 
| Will you throw on the wrong number of members in a tuple?  etc.  A dictionary
| mapping avoids all that hassle.

Now, my prediction was that you will see this AFTER you try to write
generic support the way you describe it.

Tuple parameters to Python system functions are standardized by Python -
that is, regardless of the system's layout for struct stat or whatever,
Python's tuple order is the same.  So you don't worry where pid goes,
it goes where the Python API says it goes.

That API isn't very flexible about system-dependent struct members, but
that has a good side - Linux programmers won't unconsciously make their
programs non-portable, as they manage to do surprisingly often.  And it
makes Python itself simpler, you don't need the autoconfig logic for
HAVE_STAT_BLKSIZE etc.  And the implementation issues are simpler with
simple tuple inputs and outputs, which really is important with C modules.

|> Now one thing you might try, if you would like a fun project, is a
|> automatic module builder that would, as needed, construct C modules
|> that work exactly like you describe.
|
| I'm not sure I understand exactly what the application here is.  If you could
| broaden the description some I might consider building it.

I really don't care much for the ioctl packed struct system myself,
I think it's unworkable for serious applications, for exactly the
reasons you mention.  It's also foolish to assign symbolic ioctl
parameter values in a Python program, knowing very well that on
another platform they'll be invalid.

Your solution isn't entirely wrong.  I don't know if I like it better
than a class instance -- I mean, isn't flock.pid better than flock['pid']?
Or a C type implemented by the C module specifically for the purpose,
accepting only supported types for supported attributes.  I don't care
to see it in the core distribution however it comes out, because it's 
loat on behalf of inherently non-portable functionality, but then that
isn't the most useful place for it anyway - if you want access to
non-portable features, you're in trouble if you have to download the
support from python.org.  I just have this vague idea about automated
procedures building a custom module with this support, for the rare
case where it's really useful.  That would put a module like that
within reach of someone who has a system specific application but
isn't capable of coding it from scratch.

	Donn Cave, donn at u.washington.edu