--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
of
--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.
--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
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
handling
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. When signals
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
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 API
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 deliver
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()
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
--On Tuesday, April 03, 2001 18:17:30 -0700 Fabio Riccardi
[EMAIL PROTECTED] wrote:
Alan Cox wrote:
Indeed, I'm using RT sigio/sigwait event scheduling, bare clone threads
and zero-copy io.
Fabio, I'm working on a similar solution, although I'm experimenting with
SGI's KAIO patch to see
--On Wednesday, April 04, 2001 15:16:32 -0700 Tim Wright [EMAIL PROTECTED]
wrote:
On Wed, Apr 04, 2001 at 03:23:34PM +0200, Ingo Molnar wrote:
nope. The goal is to satisfy runnable processes in the range of NR_CPUS.
You are playing word games by suggesting that the current behavior
prefers
--On Wednesday, April 04, 2001 21:30:51 -0400 "Carey B. Stortz"
[EMAIL PROTECTED] wrote:
either stayed the same or had a performance increase. A general decrease
started around kernel 2.1.32, then performance drastically fell at kernel
2.3.20. There is an Excel graph which shows the trend at:
--On Friday, April 13, 2001 04:45:07 -0400 Dan Maas [EMAIL PROTECTED] wrote:
IIRC the problem with implementing asynchronous *disk* I/O in Linux today
is that the filesystem code assumes synchronous I/O operations that block
the whole process/thread. So implementing "real" asynch I/O (without
Davide Libenzi wrote:
Yes, that is some very interesting data IMO. I did not bench the GUASI
(userspace async thread library) against AIO, but those numbers show that a
*userspace* async syscall wrapper interface performs in the ballpark of AIO.
This leads to some hope about the ability to
--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
--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
--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
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.
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
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
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
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
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
--On Tuesday, April 03, 2001 18:17:30 -0700 Fabio Riccardi
<[EMAIL PROTECTED]> wrote:
> Alan Cox wrote:
> Indeed, I'm using RT sigio/sigwait event scheduling, bare clone threads
> and zero-copy io.
Fabio, I'm working on a similar solution, although I'm experimenting with
SGI's KAIO patch to
--On Wednesday, April 04, 2001 15:16:32 -0700 Tim Wright <[EMAIL PROTECTED]>
wrote:
> On Wed, Apr 04, 2001 at 03:23:34PM +0200, Ingo Molnar wrote:
>> nope. The goal is to satisfy runnable processes in the range of NR_CPUS.
>> You are playing word games by suggesting that the current behavior
>>
--On Wednesday, April 04, 2001 21:30:51 -0400 "Carey B. Stortz"
<[EMAIL PROTECTED]> wrote:
> either stayed the same or had a performance increase. A general decrease
> started around kernel 2.1.32, then performance drastically fell at kernel
> 2.3.20. There is an Excel graph which shows the
--On Thursday, April 05, 2001 15:38:41 -0700 "Timothy D. Witham"
<[EMAIL PROTECTED]> wrote:
> Database performance:
> Raw storage I/O performance
>OLTP workload
You probably want to add an OLAP scenario as well.
--Chris
-
To unsubscribe from this list: send
--On Friday, April 13, 2001 04:45:07 -0400 Dan Maas <[EMAIL PROTECTED]> wrote:
> IIRC the problem with implementing asynchronous *disk* I/O in Linux today
> is that the filesystem code assumes synchronous I/O operations that block
> the whole process/thread. So implementing "real" asynch I/O
Davide Libenzi wrote:
Yes, that is some very interesting data IMO. I did not bench the GUASI
(userspace async thread library) against AIO, but those numbers show that a
*userspace* async syscall wrapper interface performs in the ballpark of AIO.
This leads to some hope about the ability to
31 matches
Mail list logo
