Re: [ProgSoc] programming a server

[David Shoon <dshoon@nospam.progsoc.uts.edu.au>]

On Sun, 3 Jun 2001, Paul Cameron wrote:

> On Wed, May 30, 2001 at 05:56:31PM +1000, Matt wrote:
> > 
> > On Wed, May 30, 2001 at 05:47:47PM +1000, vik wrote:
> > > My question is, what would be a nice way to limit the number of
> > > connections? atm I have a counter which is incremented each time a
> > > child is spawned, and when this reaches a certain number, the parent
> > > waits for any child to finish (via the wait() fn). However, this
> > > means the parent only waits when the number of children is at its
> > > limit, which is kinda messy. Also, I can't b stuffed learning about
> > > signals. any ideas?
> > 
> > have a look at wait4() or waitpid(). waitpid() is a part of SuS as i
> > understand it but wait4() only exists in BSD and Linux. both these
> > functions allow you to check for children without blocking so you can
> > do it as soon as you have more than 1 child. also learning about
> > signals is a core competancy in unix. without it it is very difficult
> > to write good interactive code.

Specifically, it's the WNOHANG option. :)

> Ok, I have a sort of related question, for coding styles that work ...
> 
> When working with synchronous comms using a select()/poll() model,
> how do you handle slow syscalls? That is to say, how do you deal with
> syscall failure caused by signals (be they SIGCHLD or SIGPIPE)?
>

Which syscalls are you referring to in particular? BTW, most syscalls that
sends a SIGPIPE signal also return EPIPE in the errno. (which means that
you can block sigpipe and just check errno instead)
 
> Possibilities:
>   o) Deal with the signals on an ad hoc basis
>   o) block all signals when in a block performing many syscalls,
>      perhaps longjmp on errors (sigprocmask and friends)
>   o) change the semantics of 'slow' syscalls (?? i think I read this
>      somewhere, but don't remember, perhaps it was a strange dream)
> 
> And do you prefer select() or poll()? Is using either computationally
> more intensive?
> 

Poll is known to be slightly faster on Linux/glibc systems. (where poll is
implemented in the kernel, compared to poll() emulation)


cheers,

Dave


-
You are subscribed to the progsoc mailing list. To unsubscribe, send a
message containing "unsubscribe" to progsoc-request@nospam.progsoc.uts.edu.au.
If you are having trouble, ask owner-progsoc@nospam.progsoc.uts.edu.au for help.