Re: conserver eventually goes catatonic after SIGPIPE (on NetBSD)

[ On Tuesday, May 28, 2002 at 18:06:18 (-0700), Bryan Stansell wrote: ]
> Subject: Re: conserver eventually goes catatonic after SIGPIPE (on NetBSD)
>
> yeah, i'm not sure myself.  i've been adding and changing things and
> trying to not break older systems, but at this point, i have no idea if
> i've succeeded.  i haven't heard complaints, so that's promising, but i
> don't want to just assume everyone is posix-compliant or has foo and
> bar or whatever.  i wish i knew for sure.  so, i'd like to try and keep
> it as forgiving as possible.

Well, according to Stevens' APUE, waitpid() is new with POSIX.1.
However conserver currently uses it (as per the note in CHANGES),
without even bothering to use an autoconf check for it....

Signal blocking can be done without using POSIX.1 sigaction() on
everything back to AT&T SysVr3(.2?), but writing the code to do it
portably, and especially testing it in this day and age, is rather
difficult.

On the other hand I've never seen a system with waitpid(2), but without
POSIX.1 signals, and I've seen almost all the possibilities....

(though in the past I've implemented a user-level waitpid() wrapper
using wait4(), and presumably such a wrapper would fool an autoconf
check anyway....)

So, what I'm trying to say is that conserver currently requires at least
the level of POSIX.1 compliance I'm suggesting would be needed to
implement the signal-blocking fix to my chat patch.

However I'm also sort of saying that conserver could easily be made
portable in its currently released state to older *BSD systems at least
as old as 4.3BSD.  Does anyone care?  We're talking about some pretty
ancient stuff here -- even SunOS-4.0 has enough POSIX compliance.
Could anyone using conserver even test such portability any more?


> and that's one thing i'm worried about...synchronous behavior.

I'm not worried at all about synchronous behaviour in the "chat" case.
Indeed it must be synchronous -- it's equivalent to, or at least part of
the process of, the opening and initialization of the port (or telnet
connection, in my case) itself, i.e. you can't open a bunch of ports in
parallel.  It's really only possible to initialize one console at a
time.

Presumably a failed chat even requires a disconnect and later retry,
though I don't thing I've implemented quite that much yet....

Asynchronous initialization is best done by reducing the number of
consoles handled per group and forking more handler processes....
Ultimately the best case for parallel operation is one handler process
per console "port".  Personally that's the way I would have implemented
it from the get go.  It makes things a lot simpler to implement, and it
doesn't really make the reload situation any more difficult (it might
even make it easier since this way the master knows exactly which
consoles have had parameter changes and thus will know exactly which
processes will need to be restarted).  It also makes TTY signal handling
possible for true serial ports -- you make the controlling terminal for
the process be the serial port it's managing.  Currently there's no way
to handle situations where signals are generated on the serial port by
its driver, such as SIGHUP, since you can't have multiple TTYs all
sending signals to the same process.

BTW, nobody should be afraid of having one process per console port
either, even if they have a thousand console ports to manage.  This is
unix, after all!  (even if some implementations are a bit stupid about
fork(), it's not as if this application would be constantly re-forking
processes continuously)

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>