Opinion: locks, nonblock

Opinion: locks, nonblock

[Felipe Kellermann]

Greetings,

This is more a request for opinions than a question.

Last weekend I decided that I'd try to implement a native "shell file 
locking". I have made a patch to bash 3.0.14 just for experimenting:
http://fk.geek42.org/bash-3.0.14-lock.patch

The patch adds to options: exlock and nonblock.
That was just a test. exlock implements a lock to every file opened by the 
shell (using exec) and nonblock makes O_NONBLOCK'ed operations (including 
the possibly exlock'ed I/O).

My real target while making the patch was the possibility to write a zsh 
module to implement such operations in a native way. Most of these could 
very well be implemented outside the shell while others would have to be 
implemented natively in the environment.

For instance, I have been using lockfile (of procmail) to lock files for 
years. Now I'm wondering if it would not be nicer to have that operation 
natively in my zsh environment.

Some of these operations - like setting a nonblock flag to a fd, or just 
temporarily locking a fd - could help in various ways.

So, the opinions...

Does anyone implemented something like that already? Or else, does anyone 
have specific tricks to achieve similar functionality? I've researched a 
bit and found nothing.

Do you guys think it would be nice to have that functionality implemented 
natively in the shell?

Also, any pointers to implementing that functionality? Would it be better 
designed as a module or natively to the zsh? At first I thought it would 
be nice to write a module implementing something like a "generic file 
descriptior handling" operation.

Are are your opinions on these points?
Thanks,

-- 
Felipe Kellermann

Re: Opinion: locks, nonblock

[Bart Schaefer]

On Mar 24,  9:18pm, Felipe Kellermann wrote:
}
} The [bash] patch adds to options: exlock and nonblock.
} That was just a test. exlock implements a lock to every file opened
} by the shell (using exec) and nonblock makes O_NONBLOCK'ed operations
} (including the possibly exlock'ed I/O).

This strikes me as entirely the wrong way to go about this.  It's not
too horrible for the locking part -- except see below -- but there is
a pervasive assumption of blocking I/O in the pipes and redirections
model that is basic to the semantics of shell constructs.  Non-blocking
I/O should be something that's activated in a specific and very narrow
context, not turned on and off globally.

} For instance, I have been using lockfile (of procmail) to lock files for 
} years. Now I'm wondering if it would not be nicer to have that operation 
} natively in my zsh environment.

Have you looked at the source for lockfile?  It goes to considerable
lengths to employ a locking strategy that is safe across networked
file systems and a variety of operating system or C library locking
protocols, some of which depend on having the name of a file (not the
file being locked, an additional file) as a semaphore.  A simple flock()
as in your patch is not sufficient in a number of cases -- and I won't
even go into the maillock(3X) protocol, which is required on a lot more
systems than document it, though the shell probably wouldn't be locking
email delivery boxes all that often.

} Does anyone implemented something like that already? Or else, does
} anyone have specific tricks to achieve similar functionality? I've
} researched a bit and found nothing.

For non-blocking read, look at the zsh/zselect and zsh/system modules.
If you use zselect to determine which FDs are ready for reading and then
call sysread or syswrite to do the I/O, you can get the effect of a non-
blocking read without having to set the descriptor mode.  Non-blocking
write is trickier.

See also the "read" builtin with the -t and -k options.

} Do you guys think it would be nice to have that functionality
} implemented natively in the shell?

It might be useful to add a command to the zsh/system module to perform
fcntl() operations.  (Note, however, that's incompatible with flock().)
I can't decide on the best way to enumerate the possible commands, nor
on the right way to return information -- probably something like the
format used by the zsh/stat module would be appropriate.