[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ProgSoc] programming a server
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)
> 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)
You are subscribed to the progsoc mailing list. To unsubscribe, send a
message containing "unsubscribe" to firstname.lastname@example.org.
If you are having trouble, ask email@example.com for help.