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
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 signal whose handler is SIG_DFL. If you then block that
signal before changing
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
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
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
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
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 allowing
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 unblocking the
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
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 bind a
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
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 scaling.
12 matches
Mail list logo
