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 po
> 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 p
> 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
> > 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 b
> > 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
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
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
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
> 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 loa
> 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 lo
> > 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 s
> > 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
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:
> 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 fd
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. Wh
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. W
> 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,
> 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 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 fr
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 f
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 arr
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
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 ar
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 th
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 me
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 mes
28 matches
Mail list logo
