Newsgroups: comp.unix.sysv386
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!sdd.hp.com!news.cs.indiana.edu!ux1.cso.uiuc.edu!midway!clout!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Subject: Re: cu/ecu through TCP/IP (plus ecu porting status)
Message-ID: <1991May19.041007.14192@chinet.chi.il.us>
Organization: Chinet - Chicago Public Access UNIX
References: <1061@aega84.UUCP> <1991May17.171141.27309@chinet.chi.il.us> <377@tmcsys.UUCP>
Date: Sun, 19 May 1991 04:10:07 GMT

In article <377@tmcsys.UUCP> lothar@tmcsys.UUCP (L. Hirschbiegel) writes:
>[Re: RFS vs. ioctl()...]
>Sorry: as far as I know this is simply not true. 
>Anyway there is passing of different structs for other affected syscalls
>as open(), creat() lockf() and so on. You wouldn't deny they are working :-) ?
>And if there is some kind of xdr (or basically some hton* and n*toh) why
>should just ioctl() be left out? Makes no sense for me...

The other structs are known ahead of time.  Ioctl() passes structs that
are specific to the device driver so there is no general way for another
machine to interpret them.  It doesn't have to make sense, they are
the phone company...

>>In fact, I haven't been able to
>>get uucico to work over RFS to a remote device on an identical machine,
>>although cu will do it on the 386's.

>Hmmm, this can have many reasons. Dunno what didn't work with uucico, but
>cu is just needing the (shared) device and some Systems and Dialers file,
>whereas uucico would need some more shared directories over RFSnet.

No, it shouldn't need any other shared files and I could get it to
go as far as logging into the remote system but it would fail as
it started to go into the file transfer protocol.

>You are right here. But there are some hundred reasons more besides problems
>with RFS not to use uugetty. 

Huh?  I haven't had any problems at all with uugetty.  I'd prefer something
smarter about handling modems that tell you the speed they are using,
but other than that it works just fine.  Why don't you like it?  There
is the possibility of an incoming call being picked up by an outbound
call going off-hook to dial, but the only way to completely close the
window on that is to not enable auto-answer on the modem until you
see it say 'RING', then obtain the lock before picking up.

>>uucico's debug output indicate that it succeeded in obtaining
>>a lockfile but still failed to get the kernel lock (which really
>>indicates that the lockfile scheme didn't work).

>This is really strange. All I can say is that it worked here.
>Buggy RFS version? Configuration problem? 

No, this didn't involve RFS at all - it was entirely local.  It just
shows that lockfile locking is not robust (actually it is only a
problem to remove lockfiles that some other process created).

>>I'm pretty sure it isn't possible to do locks right in a shell script.
>>Creating a tmp file and using /etc/link to attempt to rename it to
>>the agreed-upon lockfile name is OK if it works, but you can never
>>safely test or remove an existing file. 

>Do you expect race conditions or what?

Of course I expect race conditions.  The whole idea of trying to lock
the resource is that you expect more than one process to try to use
it at once.  Since no operation you can use to test the validity of
a lockfile can be atomic with removing it or creating your own, you
never know that the file you remove is the same one you tested or
one belonging to a process running a time-slice ahead of you that
just went through the same steps.  As it happens, uucico would eventually
give up and retry later if it did happen to get two copies running
on the same line, but other programs might not be so forgiving.

Les Mikesell
  les@chinet.chi.il.us