Terry Lambert wrote:
>
> > > Which is precisely why you need to know where in the chain of events this
> > > happened. Otherwise if I see
> > > 'read on fd 5'
> > > 'read on fd 5'
> > > How do I know which read is for which fd in the multithreaded case
> >
> > That can't happen,
> > Which is precisely why you need to know where in the chain of events this
> > happened. Otherwise if I see
> >
> > 'read on fd 5'
> > 'read on fd 5'
> >
> > How do I know which read is for which fd in the multithreaded case
>
> That can't happen, can it? Let's say the
* Dan Kegel <[EMAIL PROTECTED]> [001027 09:40] wrote:
> Alan Cox wrote:
> > > > kqueue currently does this; a close() on an fd will remove any pending
> > > > events from the queues that they are on which correspond to that fd.
> > >
> > > the application of a close event. What can I say, "the
Alan Cox wrote:
> > > kqueue currently does this; a close() on an fd will remove any pending
> > > events from the queues that they are on which correspond to that fd.
> >
> > the application of a close event. What can I say, "the fd formerly known
> > as X" is now gone? It would be incorrect
* Jamie Lokier <[EMAIL PROTECTED]> [001027 08:21] wrote:
> Alfred Perlstein wrote:
> > > If a programmer does not ever wish to block under any circumstances, it's
> > > his obligation to communicate this desire to the implementation. Otherwise,
> > > the implementation can block if it doesn't
Alfred Perlstein wrote:
> > If a programmer does not ever wish to block under any circumstances, it's
> > his obligation to communicate this desire to the implementation. Otherwise,
> > the implementation can block if it doesn't have data or an error available
> > at the instant 'read' is called,
Alfred Perlstein wrote:
If a programmer does not ever wish to block under any circumstances, it's
his obligation to communicate this desire to the implementation. Otherwise,
the implementation can block if it doesn't have data or an error available
at the instant 'read' is called,
* Jamie Lokier [EMAIL PROTECTED] [001027 08:21] wrote:
Alfred Perlstein wrote:
If a programmer does not ever wish to block under any circumstances, it's
his obligation to communicate this desire to the implementation. Otherwise,
the implementation can block if it doesn't have data or an
Alan Cox wrote:
kqueue currently does this; a close() on an fd will remove any pending
events from the queues that they are on which correspond to that fd.
the application of a close event. What can I say, "the fd formerly known
as X" is now gone? It would be incorrect to say that
* Dan Kegel [EMAIL PROTECTED] [001027 09:40] wrote:
Alan Cox wrote:
kqueue currently does this; a close() on an fd will remove any pending
events from the queues that they are on which correspond to that fd.
the application of a close event. What can I say, "the fd formerly known
Which is precisely why you need to know where in the chain of events this
happened. Otherwise if I see
'read on fd 5'
'read on fd 5'
How do I know which read is for which fd in the multithreaded case
That can't happen, can it? Let's say the following happens:
Terry Lambert wrote:
Which is precisely why you need to know where in the chain of events this
happened. Otherwise if I see
'read on fd 5'
'read on fd 5'
How do I know which read is for which fd in the multithreaded case
That can't happen, can it? Let's say
* Alan Cox <[EMAIL PROTECTED]> [001026 18:33] wrote:
> > the application of a close event. What can I say, "the fd formerly known
> > as X" is now gone? It would be incorrect to say that "fd X was closed",
> > since X no longer refers to anything, and the application may have reused
> > that fd
> the application of a close event. What can I say, "the fd formerly known
> as X" is now gone? It would be incorrect to say that "fd X was closed",
> since X no longer refers to anything, and the application may have reused
> that fd for another file.
Which is precisely why you need to know
On Fri, Oct 27, 2000 at 01:50:40AM +0100, Alan Cox wrote:
> > kqueue currently does this; a close() on an fd will remove any pending
> > events from the queues that they are on which correspond to that fd.
>
> This seems an odd thing to do. Surely what you need to do is to post a
> 'close
* Alan Cox <[EMAIL PROTECTED]> [001026 17:50] wrote:
> > kqueue currently does this; a close() on an fd will remove any pending
> > events from the queues that they are on which correspond to that fd.
>
> This seems an odd thing to do. Surely what you need to do is to post a
> 'close completed'
> kqueue currently does this; a close() on an fd will remove any pending
> events from the queues that they are on which correspond to that fd.
This seems an odd thing to do. Surely what you need to do is to post a
'close completed' event to the queue. This also makes more sense when you
have a
This is a long posting, with a humble beginning, but it has
a point. I'm being complete so that no one is left in the
dark, or in any doubt as to what that point is. That means
rehashing some history.
This posting is not really about select or Linux: it's about
interfaces. Like cached state,
On Thu, Oct 26, 2000 at 02:16:28AM -0700, Gideon Glass wrote:
> Jonathan Lemon wrote:
> >
> > Also, consider the following scenario for the proposed get_event():
> >
> >1. packet arrives, queues an event.
> >2. user retrieves event.
> >3. second packet arrives, queues event again.
>
Jonathan Lemon wrote:
>
> Also, consider the following scenario for the proposed get_event():
>
>1. packet arrives, queues an event.
>2. user retrieves event.
>3. second packet arrives, queues event again.
>4. user reads() all data.
>
> Now, next time around the loop, we get a
> * David Schwartz <[EMAIL PROTECTED]> [001025 15:35] wrote:
> >
> > If a programmer does not ever wish to block under any
> circumstances, it's
> > his obligation to communicate this desire to the
> implementation. Otherwise,
> > the implementation can block if it doesn't have data or an
> error
[ ... blocking read after signalling that data is available ... ]
> Yes, and as you mentioned, it was _bugs_ in the operating system
> that did this.
I think it's reasonable for the OS to discard, for example,
connection requests which are not serviced in a reasonable
time window. Likewise,
[ ... blocking read after signalling that data is available ... ]
Yes, and as you mentioned, it was _bugs_ in the operating system
that did this.
I think it's reasonable for the OS to discard, for example,
connection requests which are not serviced in a reasonable
time window. Likewise, it's
* David Schwartz [EMAIL PROTECTED] [001025 15:35] wrote:
If a programmer does not ever wish to block under any
circumstances, it's
his obligation to communicate this desire to the
implementation. Otherwise,
the implementation can block if it doesn't have data or an
error available
On Thu, Oct 26, 2000 at 02:16:28AM -0700, Gideon Glass wrote:
Jonathan Lemon wrote:
Also, consider the following scenario for the proposed get_event():
1. packet arrives, queues an event.
2. user retrieves event.
3. second packet arrives, queues event again.
4. user
This is a long posting, with a humble beginning, but it has
a point. I'm being complete so that no one is left in the
dark, or in any doubt as to what that point is. That means
rehashing some history.
This posting is not really about select or Linux: it's about
interfaces. Like cached state,
kqueue currently does this; a close() on an fd will remove any pending
events from the queues that they are on which correspond to that fd.
This seems an odd thing to do. Surely what you need to do is to post a
'close completed' event to the queue. This also makes more sense when you
have a
* Alan Cox [EMAIL PROTECTED] [001026 17:50] wrote:
kqueue currently does this; a close() on an fd will remove any pending
events from the queues that they are on which correspond to that fd.
This seems an odd thing to do. Surely what you need to do is to post a
'close completed' event to
On Fri, Oct 27, 2000 at 01:50:40AM +0100, Alan Cox wrote:
kqueue currently does this; a close() on an fd will remove any pending
events from the queues that they are on which correspond to that fd.
This seems an odd thing to do. Surely what you need to do is to post a
'close completed'
the application of a close event. What can I say, "the fd formerly known
as X" is now gone? It would be incorrect to say that "fd X was closed",
since X no longer refers to anything, and the application may have reused
that fd for another file.
Which is precisely why you need to know where
* Alan Cox [EMAIL PROTECTED] [001026 18:33] wrote:
the application of a close event. What can I say, "the fd formerly known
as X" is now gone? It would be incorrect to say that "fd X was closed",
since X no longer refers to anything, and the application may have reused
that fd for
* David Schwartz <[EMAIL PROTECTED]> [001025 15:35] wrote:
>
> If a programmer does not ever wish to block under any circumstances, it's
> his obligation to communicate this desire to the implementation. Otherwise,
> the implementation can block if it doesn't have data or an error available
> at
On Wed, Oct 25, 2000 at 11:27:09AM -0400, Simon Kirby wrote:
> On Wed, Oct 25, 2000 at 01:02:46AM -0500, Jonathan Lemon wrote:
>
> > ends up making the job of the application harder. A simple example
> > to illustrate the point: what if the application does not choose
> > to read all the data
> On Wed, Oct 25, 2000 at 03:11:37PM -0700, David Schwartz wrote:
> >
> > > Now, next time around the loop, we get a notification for an event
> > > when there is no data to read. The application now must be prepared
> > > to handle this case (meaning no blocking read() calls can be used).
> >
On Wed, Oct 25, 2000 at 03:11:37PM -0700, David Schwartz wrote:
>
> > Now, next time around the loop, we get a notification for an event
> > when there is no data to read. The application now must be prepared
> > to handle this case (meaning no blocking read() calls can be used).
> > --
> >
> Now, next time around the loop, we get a notification for an event
> when there is no data to read. The application now must be prepared
> to handle this case (meaning no blocking read() calls can be used).
> --
> Jonathan
If the programmer never wants to block in a read call, he
On Wed, Oct 25, 2000 at 11:40:28AM -0700, Simon Kirby wrote:
> On Wed, Oct 25, 2000 at 12:23:07PM -0500, Jonathan Lemon wrote:
>
> > Consider a program which reads from point A, writes to point B. If
> > the buffer associated with B fills up, then we don't want to continue
> > reading from A.
>
On Wed, Oct 25, 2000 at 09:40:53PM +0200, Jamie Lokier wrote:
> Simon Kirby wrote:
> > And you'd need to take the descriptor out of the read() set in the
> > select() case anyway, so I don't really see what's different.
>
> The difference is that taking a bit out of select()'s bitmap is
>
> What applications would do better by postponing some of the reading?
> I can't think of any reason off the top of my head why an application
> wouldn't want to read everything it can. Doing everything in smaller
> chunks would increase overhead (but maybe reduce latencies very slightly
> --
Simon Kirby wrote:
> And you'd need to take the descriptor out of the read() set in the
> select() case anyway, so I don't really see what's different.
The difference is that taking a bit out of select()'s bitmap is
basically free. Whereas the equivalent with events is a bind_event()
system
On Wed, Oct 25, 2000 at 12:23:07PM -0500, Jonathan Lemon wrote:
> Consider a program which reads from point A, writes to point B. If
> the buffer associated with B fills up, then we don't want to continue
> reading from A.
>
> A/B may be network sockets, pipes, or ptys.
Fine, but we
On Wed, Oct 25, 2000 at 07:08:48PM +0200, Jamie Lokier wrote:
> Simon Kirby wrote:
>
> > What applications would do better by postponing some of the reading?
> > I can't think of any reason off the top of my head why an application
> > wouldn't want to read everything it can.
>
> Pipelined
On Wed, Oct 25, 2000 at 11:27:09AM -0400, Simon Kirby wrote:
> On Wed, Oct 25, 2000 at 01:02:46AM -0500, Jonathan Lemon wrote:
>
> > Yes, someone pointed me to those today. I would suggest reading
> > some of the relevant literature before embarking on a design. My
> > paper discusses some of
Simon Kirby wrote:
> > While an 'edge-trigger' design is indeed simpler, I feel that it
> > ends up making the job of the application harder. A simple example
> > to illustrate the point: what if the application does not choose
> > to read all the data from an incoming packet? The app now has
On Wed, Oct 25, 2000 at 01:02:46AM -0500, Jonathan Lemon wrote:
> Yes, someone pointed me to those today. I would suggest reading
> some of the relevant literature before embarking on a design. My
> paper discusses some of the issues, and Mogul/Banga make some good
> points too.
>
> While an
On Wed, Oct 25, 2000 at 01:02:46AM -0500, Jonathan Lemon wrote:
Yes, someone pointed me to those today. I would suggest reading
some of the relevant literature before embarking on a design. My
paper discusses some of the issues, and Mogul/Banga make some good
points too.
While an
Simon Kirby wrote:
While an 'edge-trigger' design is indeed simpler, I feel that it
ends up making the job of the application harder. A simple example
to illustrate the point: what if the application does not choose
to read all the data from an incoming packet? The app now has to
On Wed, Oct 25, 2000 at 11:27:09AM -0400, Simon Kirby wrote:
On Wed, Oct 25, 2000 at 01:02:46AM -0500, Jonathan Lemon wrote:
Yes, someone pointed me to those today. I would suggest reading
some of the relevant literature before embarking on a design. My
paper discusses some of the
On Wed, Oct 25, 2000 at 07:08:48PM +0200, Jamie Lokier wrote:
Simon Kirby wrote:
What applications would do better by postponing some of the reading?
I can't think of any reason off the top of my head why an application
wouldn't want to read everything it can.
Pipelined server.
On Wed, Oct 25, 2000 at 12:23:07PM -0500, Jonathan Lemon wrote:
Consider a program which reads from point A, writes to point B. If
the buffer associated with B fills up, then we don't want to continue
reading from A.
A/B may be network sockets, pipes, or ptys.
Fine, but we can
Simon Kirby wrote:
And you'd need to take the descriptor out of the read() set in the
select() case anyway, so I don't really see what's different.
The difference is that taking a bit out of select()'s bitmap is
basically free. Whereas the equivalent with events is a bind_event()
system call.
What applications would do better by postponing some of the reading?
I can't think of any reason off the top of my head why an application
wouldn't want to read everything it can. Doing everything in smaller
chunks would increase overhead (but maybe reduce latencies very slightly
-- albeit
On Wed, Oct 25, 2000 at 09:40:53PM +0200, Jamie Lokier wrote:
Simon Kirby wrote:
And you'd need to take the descriptor out of the read() set in the
select() case anyway, so I don't really see what's different.
The difference is that taking a bit out of select()'s bitmap is
basically
On Wed, Oct 25, 2000 at 11:40:28AM -0700, Simon Kirby wrote:
On Wed, Oct 25, 2000 at 12:23:07PM -0500, Jonathan Lemon wrote:
Consider a program which reads from point A, writes to point B. If
the buffer associated with B fills up, then we don't want to continue
reading from A.
A/B
Now, next time around the loop, we get a notification for an event
when there is no data to read. The application now must be prepared
to handle this case (meaning no blocking read() calls can be used).
--
Jonathan
If the programmer never wants to block in a read call, he should
On Wed, Oct 25, 2000 at 03:11:37PM -0700, David Schwartz wrote:
Now, next time around the loop, we get a notification for an event
when there is no data to read. The application now must be prepared
to handle this case (meaning no blocking read() calls can be used).
--
On Wed, Oct 25, 2000 at 11:27:09AM -0400, Simon Kirby wrote:
On Wed, Oct 25, 2000 at 01:02:46AM -0500, Jonathan Lemon wrote:
ends up making the job of the application harder. A simple example
to illustrate the point: what if the application does not choose
to read all the data from an
* David Schwartz [EMAIL PROTECTED] [001025 15:35] wrote:
If a programmer does not ever wish to block under any circumstances, it's
his obligation to communicate this desire to the implementation. Otherwise,
the implementation can block if it doesn't have data or an error available
at the
On Tue, Oct 24, 2000 at 09:45:14PM -0700, Dan Kegel wrote:
> If you haven't already, you might peek at the discussion on
> linux-kernel. Linus seems to be on the verge of adding
> something like kqueue() to Linux, but appears opposed to
> supporting level-triggering; he likes the simplicity of
>
Johnathan,
Thanks for running that test for me! I've added your results
(plus a cautionary note about microbenchmarks and a link to
your site) to http://www.kegel.com/dkftpbench/Poller_bench.html
If you haven't already, you might peek at the discussion on
linux-kernel. Linus seems to be on the
Johnathan,
Thanks for running that test for me! I've added your results
(plus a cautionary note about microbenchmarks and a link to
your site) to http://www.kegel.com/dkftpbench/Poller_bench.html
If you haven't already, you might peek at the discussion on
linux-kernel. Linus seems to be on the
On Tue, Oct 24, 2000 at 09:45:14PM -0700, Dan Kegel wrote:
If you haven't already, you might peek at the discussion on
linux-kernel. Linus seems to be on the verge of adding
something like kqueue() to Linux, but appears opposed to
supporting level-triggering; he likes the simplicity of
edge
62 matches
Mail list logo
