fcntl semantics

[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 is
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 a
machine/compiler/OS specific packed struct in my Python code to do so.  That is
counterproductive, when, as you point out, lockf already *has* most of the code
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 the
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 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.

Andy L.