cu/ecu through TCP/IP (plus ecu porting status)

[L. Hirschbiegel]

In article <1991May19.041007.14192 at chinet.chi.il.us> les at chinet.chi.il.us (Leslie Mikesell) writes:
>
>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...

Where ends meet. This is what I said: if cpu's are similar or (even better)
equal, things will work. At least ioctl's are implemented in ISC.
(I remember some of the first RFS implementations a while ago, which still
were in the public domain. Have it somewhere buried on my archive tapes. They
didn't implement ioctl and select, so you could open, read, write and close
a remote tape drive but retensioning, erasing or rewinding the tape did
not work...:-)

>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,

Did you try "agetty", which came over usenet some time ago? It implements
exactly this. Should be quite easy to add some uugetty-like routines
for lockfile handling if you like this kind of handshaking. 

>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.

Some times ago I was in a design and implementation group for a parallel
multiprocessor OS (256 68020 cpu's). We had to spend a lot of time avoiding
deadlocks and race conditions in our system... This is a fundamental
problem. It has been shown by others that even a system with sufficient
atomic (and/or semaphore) operations will suffer from that, as long as there
is any kind of asynchronicity in message passing or data access.  Strictly 
speaking this means that ALL multitasking operating systems are basically
instable.
So far for the scientific approach.
[ maybe we should shift this discussion to comp.os.race.conditions :-) ? ]
In practice I do not care if in fifty remote accesses to my (RFS shared)
tty ports there is one race condition occuring. Just try again. I DO care if
this happens every second time, but even with a locking scheme realised by
shell scripts I'm far from that... :-)

>Les Mikesell
>  les at chinet.chi.il.us

Lothar Hirschbiegel
-- 
-----------------------------------------------
L. Hirschbiegel, AEG - A84, Frankfurt (Germany) 
email: unido!aega84!lh     tel: -49-69-66414316  
-----------------------------------------------