Just to confirm Dan. I was a fool and did not install the dummy handler for
the masked signal I was using. I added the proper code over the weekend with
no noticable effect (JDK 1.3 still sigtimedwait()'s on the signal :-().
--Chris
-
To unsubscribe from this list: send the line "unsubscribe li
On Fri, Jun 29, 2001 at 01:26:29AM -0700, Christopher Smith wrote:
> At 10:59 AM 6/28/2001 -0400, Dan Maas wrote:
> >life-threatening things like SIGTERM, SIGKILL, and SIGSEGV. The mutation
> >into queued, information-carrying siginfo signals just shows how badly we
> >need a more robust event mod
Dan Kegel wrote:
> Pseudocode:
>
> sigemptyset(&s);
> sigaddset(SIGUSR1, &s);
> fd=sigopen(&s);
> m=read(fd, buf, n*sizeof(siginfo_t))
> close(fd);
>
> should probably be equivalent to
>
> sigemptyset(&s);
> sigaddset(SIGUSR1, &s);
> struct sigaction newaction, oldaction;
> ne
On Fri, Jun 29, 2001 at 01:26:29AM -0700, Christopher Smith wrote:
> P.S.: What do you mean by explicit binding between event queues and
> threads? I'm not sure I see what this gains you.
Cache affinity presumably?
--cw
-
To unsubscribe from this list: send the line "unsubscribe linux-kerne
Christopher Smith <[EMAIL PROTECTED]> writes:
[...]
> >Signals are a pretty dopey API anyway - so instead of trying to
> >patch them up, why not think of something better for AIO?
>
> You assume that this issue only comes up when you're doing AIO. If
> we do something that makes signals work be
Christopher Smith wrote:
>
> At 07:57 PM 6/27/2001 -0700, Daniel R. Kegel wrote:
> >From: Christopher Smith <[EMAIL PROTECTED]>
> > >I guess the main thing I'm thinking is this could require some significant
> > >changes to the way the kernel behaves. Still, it's worth taking a "try it
> > >and s
Christopher Smith wrote:
>
> At 07:49 PM 6/27/2001 -0700, Daniel R. Kegel wrote:
> >Balbir Singh <[EMAIL PROTECTED]> wrote:
> > >sigopen() should be selective about the signals it allows
> > >as argument. Try and make sigopen() thread specific, so that if one
> > >thread does a sigopen(), it does
At 01:11 PM 6/28/2001 -0700, Daniel R. Kegel wrote:
>AFAIK, there's no 'read with a timeout' system call for file descriptors, so
>if you needed the equivalent of sigtimedwait(),
>you might end up doing a select on the sigopen fd, which is an extra
>system call. (I wish Posix had invented sigopen
At 10:59 AM 6/28/2001 -0400, Dan Maas wrote:
>life-threatening things like SIGTERM, SIGKILL, and SIGSEGV. The mutation
>into queued, information-carrying siginfo signals just shows how badly we
>need a more robust event model... (what would truly kick butt is a unified
>interface that could delive
At 01:58 PM 6/28/2001 +0100, John Fremlin wrote:
> Dan Kegel <[EMAIL PROTECTED]> writes:
> >A signal number cannot be opened more than once concurrently;
> >sigopen() thus provides a way to avoid signal usage clashes
> >in large programs.
>Signals are a pretty dopey
At 07:49 PM 6/27/2001 -0700, Daniel R. Kegel wrote:
>Balbir Singh <[EMAIL PROTECTED]> wrote:
> >sigopen() should be selective about the signals it allows
> >as argument. Try and make sigopen() thread specific, so that if one
> >thread does a sigopen(), it does not imply it will do all the signal
>
At 03:57 PM 6/28/2001 +0200, Heusden, Folkert van wrote:
>[...]
> >A signal number cannot be opened more than once concurrently;
> >sigopen() thus provides a way to avoid signal usage clashes
> >in large programs.
>YOU> Signals are a pretty dopey API anyway -
>
>Exactly. Wh
At 07:57 PM 6/27/2001 -0700, Daniel R. Kegel wrote:
>From: Christopher Smith <[EMAIL PROTECTED]>
> >I guess the main thing I'm thinking is this could require some significant
> >changes to the way the kernel behaves. Still, it's worth taking a "try it
> >and see approach". If anyone else thinks th
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
> > > > s
John Fremlin wrote:
> >A signal number cannot be opened more than once concurrently;
> >sigopen() thus provides a way to avoid signal usage clashes
> >in large programs.
>
> Signals are a pretty dopey API anyway - so instead of trying to patch
> them up, why not think of s
> admit that UNIX has a crappy event model, and implement something like Win32
> GetMessage =)...
Thats a subset of the real time signal model already in Linux. Just block the
signal and wait for it..
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messa
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, ch
> Signals are a pretty dopey API anyway - so instead of trying to patch
> them up, why not think of something better for AIO?
I have to agree, in a way... At some point we need to swallow our pride,
admit that UNIX has a crappy event model, and implement something like Win32
GetMessage =)...
I'v
[...]
>A signal number cannot be opened more than once concurrently;
>sigopen() thus provides a way to avoid signal usage clashes
>in large programs.
YOU> Signals are a pretty dopey API anyway -
Exactly. When signals were made up, signalhandlers were supposed to
not so mu
Dan Kegel <[EMAIL PROTECTED]> writes:
[...]
>A signal number cannot be opened more than once concurrently;
>sigopen() thus provides a way to avoid signal usage clashes
>in large programs.
Signals are a pretty dopey API anyway - so instead of trying to patch
them
|
|> Let me know, when somebody has a patch or needs help, I would like to
|> help or take a look at it.
|
|Maybe we can both hack on this.
|
Sure, that should be interesting, did you have something in mind ? We can
start right away.
-
To unsubscribe from this list: send the line "unsubscribe li
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
--On Wednesday, June 27, 2001 11:18:28 +0200 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 si
--On Wednesday, June 27, 2001 11:51:36 +0530 Balbir Singh
<[EMAIL PROTECTED]> wrote:
> Shouldn't there be a sigclose() and other operations to make the API
Wouldn't the existing close() be good enough for that?
> orthogonal. sigopen() should be selective about the signals it allows
> as argument
Dan Kegel wrote:
>That signal is no longer delivered normally or available for
>pickup with sigwait() et al. Instead, it must be picked up by
>calling read() on the file descriptor returned by sigwait();
>the buffer passed to read() must have a size which is a
>
Shouldn't there be a sigclose() and other operations to make the API
orthogonal. sigopen() should be selective about the signals it allows
as argument. Try and make sigopen() thread specific, so that if one
thread does a sigopen(), it does not imply it will do all the signal
handling for all the t
--On Tuesday, June 26, 2001 05:54:37 -0700 Dan Kegel <[EMAIL PROTECTED]> wrote:
> Once upon a time a hacker named Xman
> wrote a library that used aio, and decided
> to use sigtimedwait() to pick up completion
> notifications. It worked well, and his I/O
> was blazing fast (since was using a copy
Once upon a time a hacker named Xman
wrote a library that used aio, and decided
to use sigtimedwait() to pick up completion
notifications. It worked well, and his I/O
was blazing fast (since was using a copy
of Linux that was patched to have good aio).
But when he tried to integrate his library
i
30 matches
Mail list logo
