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

On Wed, May 29, 2002 at 12:40:29PM -0400, Greg A. Woods wrote:
> 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....

doh!  shows you how good my memory is - i totally forgot i introduced
that dependency.  cool....posix it is.

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

that's good to hear.

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

my question as well.  but, at this point, i would be more scared than
worried about compatibility if someone really wanted to run conserver
under something so old.

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

well, that's true, it does only initialize things one at a time, but in
the case of '|' syntax consoles, all that requires is a fork of a
process.  could a similar mode of thinking could be used for the
chat-based consoles?

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

well, actually, maybe they should.  in the past, i've seen multi-gig
systems run low on vm because of conserver's footprint.  and that was
with 32 consoles per process (they had a *lot* of consoles - heck,
still do, as far as i know).  that was pre-7.2.0, so it shouldn't be as
much of an issue now, but it still could be a concern.  i personally
like the idea of being able to use a relatively low-end machine as a
console server (i can't count the number of times i've heard of
infrastructure machines like this left out of budgets or seen as
unimportant by management or just added to an already loaded admin
box).  and there are other possibilities - cyclades ts terminal
servers, for example, run linux and can cross-compile conserver to run
on it (one person has reported success doing this).  i'm not sure if 48
processes would kill the box or not (or if the memory usage would), but
this too would be a nice situation to handle (regardless of
manufacturer).

so, there's a few more scenarios for everyone.  posix is definitely
already a requirement (you know, the more i think about this the more i
remember deciding posix wouldn't be a big deal, hence the change in
7.1.0) so further posix requirements are no big deal (now if i can just
remember that!).  as for the other stuff, being as responsive as
possible is my goal.

Bryan