Jamie wrote:
> Daniel R. Kegel wrote:
> > Christopher Smith <[EMAIL PROTECTED]> wrote:
> > > Jamie Lokier <[EMAIL PROTECTED]> wrote:
> > > > Btw, this functionality is already available using sigaction(). Just
> > > > search for a si
Christopher Smith <[EMAIL PROTECTED]> wrote:
> Jamie Lokier <[EMAIL PROTECTED]> wrote:
> > Btw, this functionality is already available using sigaction(). Just
> > search for a signal whose handler is SIG_DFL. If you then block that
> > signal before changing, checking the result, and unblockin
From: Christopher Smith <[EMAIL PROTECTED]>
>> [ sigopen() proposal ]
>... From a programming standpoint, this
>looks like a really nice approach. I must say I prefer this approach to the
>various "event" strategies I've seen to date, as it fixes the primary
>problem with signals, while still a
Balbir Singh <[EMAIL PROTECTED]> wrote:
>Shouldn't there be a sigclose() and other operations to make the API
>orthogonal.
No, plain old close() on the file descriptor returned by sigopen()
would do the trick.
>sigopen() should be selective about the signals it allows
>as argument. Try and make
Ashok wrote:
> Is there a method to schedule user mode code from
> kernel agent? ...
> windows 2000 offers 2 such facilities. (APC or async
> procedure calls) where a thread can block and when
> ready will be woken via the kernel agent and can run a
> user supplied function.
>
> or a method to bin
Andrea Arcangeli wrote:
> Petru Paler wrote:
> > This is one of the main thttpd design points: run in a select() loop. Since
> > it is intended for mainly static workloads, it performs quite well...
>
> It can't scale in SMP.
thttpd is i/o bound, not CPU bound, so there's no need for SMP sca
6 matches
Mail list logo
