On Jul 07, 1999 at 11:41:35AM -0400, Zach Brown wrote:
Well, how about the kernel passes siginfo and siginfo_cancel events
up to userland, siginfo will remove any siginfo's from its buffer
that it sees a siginfo_cancel event for -- naturally we need a flag
to tell siginfo when to poll for
could buffer siginfo's in user space, although this introduces
complexity if you want the ability to cancel queued signals...
yes, that is the hard part :)
Well, how about the kernel passes siginfo and siginfo_cancel events
up to userland, siginfo will remove any siginfo's from its buffer
Well, how about the kernel passes siginfo and siginfo_cancel events
up to userland, siginfo will remove any siginfo's from its buffer
that it sees a siginfo_cancel event for -- naturally we need a flag
to tell siginfo when to poll for events, this flag would be
set by the function which
On Jul 07, 1999 at 11:41:35AM -0400, Zach Brown wrote:
Well, how about the kernel passes siginfo and siginfo_cancel events
up to userland, siginfo will remove any siginfo's from its buffer
that it sees a siginfo_cancel event for -- naturally we need a flag
to tell siginfo when to poll for
Also, you really want to return more than one event at at time in
order to amortize the cost of the system call over several events, this
doesn't seem possible with callbacks (or upcalls).
yes, that would be a nice behaviour, but I haven't seen it become a real
issue yet. the
How about a modified sigwaitinfo that will return a number of waiting
siginfo -- of course this introduces the problem of deciding how long
to wait for new additions to the queue before returning. This is
you'd just have a 'give me up to X' parameter, if you get a single one
under high load
On Jul 07, 1999 at 01:10:38AM -0400, Zach Brown wrote:
the sigio/siginfo model is a few orders of magnitude cheaper than
poll/select as you scale the number of fds you're watching. The reasons
for this being that select()/poll() have that large chunk of state to
throw around every syscall,
Also, you really want to return more than one event at at time in
order to amortize the cost of the system call over several events, this
doesn't seem possible with callbacks (or upcalls).
yes, that would be a nice behaviour, but I haven't seen it become a real
issue yet. the
How about a modified sigwaitinfo that will return a number of waiting
siginfo -- of course this introduces the problem of deciding how long
to wait for new additions to the queue before returning. This is
you'd just have a 'give me up to X' parameter, if you get a single one
under high load
On Jul 07, 1999 at 01:10:38AM -0400, Zach Brown wrote:
the sigio/siginfo model is a few orders of magnitude cheaper than
poll/select as you scale the number of fds you're watching. The reasons
for this being that select()/poll() have that large chunk of state to
throw around every syscall,
On Mon, 5 Jul 1999, Jonathan Lemon wrote:
Yes, but I also need support for temporarily de-registering interest
in an fd, as well selectively choosing read/write/close events.
yeah, this isn't terribly doable in the sigio/signal model. as you note
later, this is indeed edge triggered so if you
On Sun, 4 Jul 1999, Jonathan Lemon wrote:
On Jul 07, 1999 at 11:15:13AM +0100, Doug Rabson wrote:
In essence, I want to move the large "struct pollfd" array that I
have into the kernel, and then instruct the kernel to add/remove
entries from this array, and only return the array
On 4 Jul, Doug Rabson wrote:
On Sun, 4 Jul 1999, Jonathan Lemon wrote:
On Jul 07, 1999 at 11:15:13AM +0100, Doug Rabson wrote:
In essence, I want to move the large "struct pollfd" array that I
have into the kernel, and then instruct the kernel to add/remove
entries from this array,
On Sun, 4 Jul 1999, Jonathan Lemon wrote:
I would think that a system that uses callbacks (like POSIX's completion
signals) would be more expensive than a call like poll() or select().
the sigio/siginfo model is a few orders of magnitude cheaper than
poll/select as you scale the number of fds
On Sun, 4 Jul 1999, Jonathan Lemon wrote:
This is an earlier posting that I attempted to make, perhaps
it can provide a starting point for discussion. While this
is already implemented, I'm not adverse to tossing it all for
something better.
--
Jonathan
- Forwarded message from
On Jul 07, 1999 at 11:15:13AM +0100, Doug Rabson wrote:
In essence, I want to move the large struct pollfd array that I
have into the kernel, and then instruct the kernel to add/remove
entries from this array, and only return the array subset which
has activity.
How does the kernel
On Sun, 4 Jul 1999, Jonathan Lemon wrote:
On Jul 07, 1999 at 11:15:13AM +0100, Doug Rabson wrote:
In essence, I want to move the large struct pollfd array that I
have into the kernel, and then instruct the kernel to add/remove
entries from this array, and only return the array subset
On 4 Jul, Doug Rabson wrote:
On Sun, 4 Jul 1999, Jonathan Lemon wrote:
On Jul 07, 1999 at 11:15:13AM +0100, Doug Rabson wrote:
In essence, I want to move the large struct pollfd array that I
have into the kernel, and then instruct the kernel to add/remove
entries from this array,
I'd like to open discussion on adding a new interface to FreeBSD,
specifically, a variant of poll().
The problem is that poll() (and select(), as well) do not scale
well as the number of open file descriptors increases. When there
are a large number of descriptors under consideration,
On Jul 07, 1999 at 01:37:13PM -0700, Mike Smith wrote:
I'd like to open discussion on adding a new interface to FreeBSD,
specifically, a variant of poll().
The problem is that poll() (and select(), as well) do not scale
well as the number of open file descriptors increases. When there
On Sun, 4 Jul 1999, Jonathan Lemon wrote:
I would think that a system that uses callbacks (like POSIX's completion
signals) would be more expensive than a call like poll() or select().
the sigio/siginfo model is a few orders of magnitude cheaper than
poll/select as you scale the number of fds
This is an earlier posting that I attempted to make, perhaps
it can provide a starting point for discussion. While this
is already implemented, I'm not adverse to tossing it all for
something better.
--
Jonathan
- Forwarded message from owner-freebsd-a...@freebsd.org -
Date: Mon, 5
22 matches
Mail list logo
