Curt Sampson <cjs@portal.ca> writes:
>On 9 Nov 1996, Charles M. Hannum wrote:
>> I'd like to see this moved into a library (say, libutil), which can be
>> used by all the programs that need it.

>> e.g.  One could imagine an
>> interface like:
>> 
>> 	opentty("/dev/ttyNN", {DIALIN,DAILOUT})
>> 	-> 0 for success
>> 	   -1 for failure, leaving errno set

>I'd rather see a separate lock function `int uucplock(char *ttydev)'
>for a few reasons:

There is no reason you can't have a uucplock() which is called by
opentty() if desired.   But yes, I think a separate locking call is
best.

You can take it a step further, and have uucplock() call a more
generic locking function which lets you specify the lock dir, lock
name and content format.  Why?  Because the guts of such a routine is
very generic and widely useful for portable interlocking b/w
processes.

For instance I have such a locking routine in each of C, perl and sh,
so that programs in each of those languages can cooperate wrt locking.
The uses are many and varied.

>One thing I'd like to see uucplock() return is the PID of the
>process that has the lock, if the tty is already locked. But this
>leaves open the question of what one returns when successful at
>locking, and what one returns when a failure of some other kind
>has occurred. Perhaps the current PID and zero, respectively?

I'd prefer it to return a boolean success/failure and pass a pointer
to pid_t if you want to know who holds the lock. 

--sjg