Xref: utzoo comp.unix.sysv386:6137 comp.unix.programmer:1374
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!zazen!wuarchive!m.cs.uiuc.edu!uiucdcs!carroll
From: carroll@cs.uiuc.edu (Alan M. Carroll)
Newsgroups: comp.unix.sysv386,comp.unix.programmer
Subject: Re: Berkley sockets
Message-ID: <1991Mar19.202408.14706@m.cs.uiuc.edu>
Date: 19 Mar 91 20:24:08 GMT
References: <1991Mar14.193619.21766@m.cs.uiuc.edu> <1991Mar13.190847.9755@watdragon.waterloo.edu> <1991Mar14.122151.21216@virtech.uucp> <16730@uudell.dell.com>
Sender: news@m.cs.uiuc.edu (News Database (admin-Mike Schwager))
Reply-To: carroll@cs.uiuc.edu (Alan M. Carroll)
Followup-To: comp.unix.programmer
Distribution: na
Organization: Technophiles Inc. - Engineers with Attitude
Lines: 56

I'm going to move this over to comp.unix.programmer, because it's
changed into a socket programming discussion.

In article <16730@uudell.dell.com>, mjhammel@Kepler.dell.com (Michael J. Hammel) writes:
> In article <1991Mar14.193619.21766@m.cs.uiuc.edu>, carroll@cs.uiuc.edu
> (Alan M. Carroll) writes:
> > [ Can't poll() listening sockets ]
> Hmm.  Maybe I don't understand the problem, but how about doing it like this:
> 
> for (;;)             /* begin infinite loop waiting for new connections */
>    {
>    if ( (t=accept(s, &isa, &i) ) < 0)
>       {
> 	...error checking code
>       }
> 
>    if ( (childpid=fork()) == 0) /* child process if fork() returns 0  */
>       {
> 	...handle connection here in child process; the child inherits the socket
>       }

There's a number of reasons for not doing it that way. The program
that I am writing is a "software bus", which accepts messages from a
set of clients, and routes those messages to the set of clients that
are interested in them. Each client connects to the bus via a scoket,
which is used to send messages to other clients, and receive them.

1. I don't like fork(), and avoid it whenever possible. Partly it's a
resource thing (particularly process slots), and partly because I
consider dealing with child processes painful, buggy, and less than
portable.

2. For connecting on sockets, I think that fork() only makes sense if
the child processes do significantly different things, as for example
in inetd. However, in my program every socket is treated in exactly
the same way. Therefore, that functionality should be moved into the
single program, to save CPU, memory, and process slots.

3. Because of the nature of the program, data from any socket can have
a need to be sent to an arbritrary subset of all the other sockets. In
order to do this using child process, each child process would have to
have a means of communicating with either all the other child
processes (and detect when any of them exited), or with the parent
process which would then forward the messages. The former is too ugly
to even discuss*. The latter can't work, because it brings us back to
the original problem - how does the parent move the data when it's
hanging on an accept?

4. I don't have threads, which might otherwise seem like a better
solution.

*This is of course the problem the program was built to solve.
-- 
Alan M. Carroll                "I hate shopping with the reality-impaired"
Epoch Development Team                 - Susan
CS Grad / U of Ill @ Urbana    ...{ucbvax,pur-ee,convex}!cs.uiuc.edu!carroll