on 19/07/2012 18:11 Davide Italiano said the following:
> On Thu, Jul 19, 2012 at 5:06 PM, Paul Albrecht wrote:
>> On Fri, 2012-07-13 at 07:22 -0500, Davide Italiano wrote:
>>> On Thu, Jul 12, 2012 at 5:25 PM, John Baldwin wrote:
On Thursday, July 12, 2012 11:08:47 am Davide Italiano wrote:
On Thu, Jul 19, 2012 at 5:06 PM, Paul Albrecht wrote:
> On Fri, 2012-07-13 at 07:22 -0500, Davide Italiano wrote:
>> On Thu, Jul 12, 2012 at 5:25 PM, John Baldwin wrote:
>> > On Thursday, July 12, 2012 11:08:47 am Davide Italiano wrote:
>> >> On Thu, Jul 12, 2012 at 4:26 PM, John Baldwin wrote:
On Fri, 2012-07-13 at 07:22 -0500, Davide Italiano wrote:
> On Thu, Jul 12, 2012 at 5:25 PM, John Baldwin wrote:
> > On Thursday, July 12, 2012 11:08:47 am Davide Italiano wrote:
> >> On Thu, Jul 12, 2012 at 4:26 PM, John Baldwin wrote:
> >> > On Thursday, July 12, 2012 9:57:16 am Ian Lepore wrot
On Friday, July 13, 2012 8:22:13 am Davide Italiano wrote:
> On Thu, Jul 12, 2012 at 5:25 PM, John Baldwin wrote:
> > On Thursday, July 12, 2012 11:08:47 am Davide Italiano wrote:
> >> On Thu, Jul 12, 2012 at 4:26 PM, John Baldwin wrote:
> >> > On Thursday, July 12, 2012 9:57:16 am Ian Lepore wro
On Thu, Jul 12, 2012 at 5:25 PM, John Baldwin wrote:
> On Thursday, July 12, 2012 11:08:47 am Davide Italiano wrote:
>> On Thu, Jul 12, 2012 at 4:26 PM, John Baldwin wrote:
>> > On Thursday, July 12, 2012 9:57:16 am Ian Lepore wrote:
>> >> On Thu, 2012-07-12 at 08:34 -0400, John Baldwin wrote:
>>
On Thu, 2012-07-12 at 10:40 -0500, Ian Lepore wrote:
> On Thu, 2012-07-12 at 17:08 +0200, Davide Italiano wrote:
> > On Thu, Jul 12, 2012 at 4:26 PM, John Baldwin wrote:
> > > On Thursday, July 12, 2012 9:57:16 am Ian Lepore wrote:
> > >> On Thu, 2012-07-12 at 08:34 -0400, John Baldwin wrote:
> >
On Thu, 2012-07-12 at 09:26 -0500, John Baldwin wrote:
> On Thursday, July 12, 2012 9:57:16 am Ian Lepore wrote:
> > On Thu, 2012-07-12 at 08:34 -0400, John Baldwin wrote:
> > > On Wednesday, July 11, 2012 5:00:47 pm Ian Lepore wrote:
> > > > On Wed, 2012-07-11 at 14:52 -0500, Paul Albrecht wrote:
On Thu, 2012-07-12 at 17:08 +0200, Davide Italiano wrote:
> On Thu, Jul 12, 2012 at 4:26 PM, John Baldwin wrote:
> > On Thursday, July 12, 2012 9:57:16 am Ian Lepore wrote:
> >> On Thu, 2012-07-12 at 08:34 -0400, John Baldwin wrote:
> >> > On Wednesday, July 11, 2012 5:00:47 pm Ian Lepore wrote:
>
On Thursday, July 12, 2012 11:08:47 am Davide Italiano wrote:
> On Thu, Jul 12, 2012 at 4:26 PM, John Baldwin wrote:
> > On Thursday, July 12, 2012 9:57:16 am Ian Lepore wrote:
> >> On Thu, 2012-07-12 at 08:34 -0400, John Baldwin wrote:
> >> > On Wednesday, July 11, 2012 5:00:47 pm Ian Lepore wrot
On Thu, Jul 12, 2012 at 4:26 PM, John Baldwin wrote:
> On Thursday, July 12, 2012 9:57:16 am Ian Lepore wrote:
>> On Thu, 2012-07-12 at 08:34 -0400, John Baldwin wrote:
>> > On Wednesday, July 11, 2012 5:00:47 pm Ian Lepore wrote:
>> > > On Wed, 2012-07-11 at 14:52 -0500, Paul Albrecht wrote:
>> >
On Thursday, July 12, 2012 9:57:16 am Ian Lepore wrote:
> On Thu, 2012-07-12 at 08:34 -0400, John Baldwin wrote:
> > On Wednesday, July 11, 2012 5:00:47 pm Ian Lepore wrote:
> > > On Wed, 2012-07-11 at 14:52 -0500, Paul Albrecht wrote:
> > > > Hi,
> > > >
> > > > Sorry about this repost but I'm co
On Thu, 2012-07-12 at 08:34 -0400, John Baldwin wrote:
> On Wednesday, July 11, 2012 5:00:47 pm Ian Lepore wrote:
> > On Wed, 2012-07-11 at 14:52 -0500, Paul Albrecht wrote:
> > > Hi,
> > >
> > > Sorry about this repost but I'm confused about the responses I received
> > > in my last post so I'm l
On Wednesday, July 11, 2012 5:00:47 pm Ian Lepore wrote:
> On Wed, 2012-07-11 at 14:52 -0500, Paul Albrecht wrote:
> > Hi,
> >
> > Sorry about this repost but I'm confused about the responses I received
> > in my last post so I'm looking for some clarification.
> >
> > Specifically, I though I co
On Wed, Jul 11, 2012 at 9:52 PM, Paul Albrecht wrote:
>
> Hi,
>
> Sorry about this repost but I'm confused about the responses I received
> in my last post so I'm looking for some clarification.
>
> Specifically, I though I could use the kqueue timer as essentially a
> "drop in" replacement for li
On Wed, 2012-07-11 at 14:52 -0500, Paul Albrecht wrote:
> Hi,
>
> Sorry about this repost but I'm confused about the responses I received
> in my last post so I'm looking for some clarification.
>
> Specifically, I though I could use the kqueue timer as essentially a
> "drop in" replacement for l
On Wed, 2012-07-11 at 04:42 -0500, Alexander Motin wrote:
> Hi.
>
> Historically FreeBSD used completely different hardware time sources for
> time keeping and time events. Not sure about 5%, but the last could be
> less precise in some cases. FreeBSD 9.0, depending on hardware, can be
> more p
On Wed, 2012-07-11 at 03:36 -0500, Harti Brandt wrote:
> On Wed, 11 Jul 2012, Peter Jeremy wrote:
>
> PJ>On 2012-Jul-10 10:03:08 -0500, Paul Albrecht wrote:
> PJ>>I have a question about the kqueue timer timeout period ... what's data
> PJ>>supposed to be? I thought it was supposed to be the peri
Hi.
Historically FreeBSD used completely different hardware time sources for
time keeping and time events. Not sure about 5%, but the last could be
less precise in some cases. FreeBSD 9.0, depending on hardware, can be
more precise because of using same time source in both cases. Also there
i
On Wed, 11 Jul 2012, Peter Jeremy wrote:
PJ>On 2012-Jul-10 10:03:08 -0500, Paul Albrecht wrote:
PJ>>I have a question about the kqueue timer timeout period ... what's data
PJ>>supposed to be? I thought it was supposed to be the period in
PJ>>milliseconds, but I seem to off by one.
PJ>>
PJ>>For ex
On 2012-Jul-10 10:03:08 -0500, Paul Albrecht wrote:
>I have a question about the kqueue timer timeout period ... what's data
>supposed to be? I thought it was supposed to be the period in
>milliseconds, but I seem to off by one.
>
>For example, if I set date (the timeout period) to 20 milliseconds
Am 25.01.2012 um 23:51 schrieb Julian Elischer:
> On 1/25/12 10:44 AM, Matthias Zitzen wrote:
>> Hello list,
>> does anybody have an idea, how to obtain the new name of a renamed file
>> after the note_rename event is fired. I'm not very familiar with
>> filesystem-operations. I checked the ty
On 1/25/12 10:44 AM, Matthias Zitzen wrote:
Hello list,
does anybody have an idea, how to obtain the new name of a renamed file after
the note_rename event is fired. I'm not very familiar with
filesystem-operations. I checked the typical functions like stat or lstat, but
these functions are w
I've added some debug output in libevent, before and after kevent function
call.
### good one request
21:30:05 evhttp_get_request_connection: fd: 196 new request from
127.0.0.1:60010
21:30:05 kq_dispatch: fd: 196 setkevent filter: EVFILT_READ flags:
EV_ADD
21:30:05 kq_dispatch: fd: 196 r
I've not seen this happen before, are you sure that libevent's kqueue
code is properly removing all the pending events for a given FD when
it's closed?
Adrian
On 19 August 2011 18:33, about bus wrote:
> Hello!
>
> I've got some interesting problem with my own server which use Libevent and
> Kq
Kip Macy wrote:
Do you have a set of regression tests for libev? It sounds like they
would worth having to regression test kqueue.
I would have thought that libevent and libev should both the checked
against kqueue. Also APR
and everything else that has support. I'm not the author of libev
On Dec 17, 2007 1:25 PM, James Mansion <[EMAIL PROTECTED]> wrote:
> Kip Macy wrote:
> >> he's just plain misinforme
> > Until we know what he is referring to we can't actually say that.
> > -Kip
> >
>
> OK he said I could post from our private email so here goes. There were
> bits in and around r
Kip Macy wrote:
he's just plain misinforme
Until we know what he is referring to we can't actually say that.
-Kip
OK he said I could post from our private email so here goes. There were
bits in and around relating to the
Solaris /dev/poll support (and the mechanism's limitations) which I
Julian Elischer wrote:
> Julian Elischer wrote:
> > James Mansion wrote:
> >> [ On the libev being unhappy with kqueue ]
> >> ...
> >> It looks like a decent library, but these comments seem
> unfortunate.
> >> Does anyone know what the author is concerned about?
> >
> > he's just plain misinform
On Dec 15, 2007, at 08:47 , Kip Macy wrote:
On 12/15/07, James Mansion <[EMAIL PROTECTED]> wrote:
Any idea what the author of libev is on about here (from
http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod):
unsigned int ev_recommended_backends ()
Return the set of all backends compiled
> > It looks like a decent library, but these comments seem unfortunate.
> > Does anyone know what the author is concerned about?
>
> he's just plain misinformed
>
Until we know what he is referring to we can't actually say that.
-Kip
___
freebsd-hacker
Julian Elischer wrote:
James Mansion wrote:
Any idea what the author of libev is on about here (from
http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod):
unsigned int ev_recommended_backends ()
Return the set of all backends compiled into this binary of libev
and also recommended for
James Mansion wrote:
Any idea what the author of libev is on about here (from
http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod):
unsigned int ev_recommended_backends ()
Return the set of all backends compiled into this binary of libev
and also recommended for this platform. This set
Actually, until recently it was broken on pipes. We've never received
any PRs to that effect so there is no way of knowing. You'll have
better luck asking the author himself.
-Kip
On 12/15/07, James Mansion <[EMAIL PROTECTED]> wrote:
> Any idea what the author of libev is on about here (from
On Sat, Dec 15, 2007 at 09:51:20AM +, James Mansion wrote:
>Kqueue deserves special mention, as at the time of this writing, it
>was broken on all BSDs except NetBSD (usually it doesn't work with
>anything but sockets and pipes, except on Darwin, where of course
>its completely
On 15/12/2007, James Mansion <[EMAIL PROTECTED]> wrote:
> |EVBACKEND_KQUEUE| (value 8, most BSD clones)
> Kqueue deserves special mention, as at the time of this writing, it
> was broken on all BSDs except NetBSD (usually it doesn't work with
> anything but sockets and pipes, except on
Cole wrote:
> If I do the above, and just keep increasing number_events and
> just mark the kevent as EV_DISABLED or EV_DELETE then all it
> does is return that event as soon as I call kevent() with the
> following values: ident : 7, filter : -1, flags : 16384
That flags value is EV_ERROR. It
Cole wrote:
> I wanted to know, what must be done when the sockets/file
> descriptors close. Do I need to decrease number_events and
> resort the events array so that all the active kevents are
> sequential without any closed sockets still in that array?
It occurs to me, you might be trying to
On Tuesday 22 May 2007 13:04:37 Suleiman Souhlal wrote:
> On May 21, 2007, at 6:48 AM, Daniel Molina Wegener wrote:
> > On Monday 21 May 2007 03:57:58 John-Mark Gurney wrote:
> >> Daniel Molina Wegener wrote this message on Sun, May 20,
> >> 2007
> >
> > at 18:31 -0400:
> >>>I'm coding an appli
On Tuesday 22 May 2007 14:06:48 Joerg Sonnenberger wrote:
> On Tue, May 22, 2007 at 10:04:37AM -0700, Suleiman Souhlal
wrote:
> > >I mean vnode events, in the manual page I see NOTE_WRITE,
> > > but I need NOTE_OPEN and NOTE_READ. Is there any chance
> > > to get these kind of events?
> >
> > They
On Tue, May 22, 2007 at 10:04:37AM -0700, Suleiman Souhlal wrote:
> >I mean vnode events, in the manual page I see NOTE_WRITE, but I
> >need NOTE_OPEN and NOTE_READ. Is there any chance to get these
> >kind of events?
>
> They should be easy to add.. All you would need to do for NOTE_OPEN
> woul
On May 21, 2007, at 6:48 AM, Daniel Molina Wegener wrote:
On Monday 21 May 2007 03:57:58 John-Mark Gurney wrote:
Daniel Molina Wegener wrote this message on Sun, May 20, 2007
at 18:31 -0400:
I'm coding an application using the kqueue facility, but
I see that I can't handle open and read e
Daniel Molina Wegener wrote this message on Mon, May 21, 2007 at 09:48 -0400:
> On Monday 21 May 2007 03:57:58 John-Mark Gurney wrote:
> > Daniel Molina Wegener wrote this message on Sun, May 20, 2007
> at 18:31 -0400:
> > >I'm coding an application using the kqueue facility, but
> > > I see t
On Monday 21 May 2007 03:57:58 John-Mark Gurney wrote:
> Daniel Molina Wegener wrote this message on Sun, May 20, 2007
at 18:31 -0400:
> >I'm coding an application using the kqueue facility, but
> > I see that I can't handle open and read events. Is planned
> > to implement these handlings in
Daniel Molina Wegener wrote this message on Sun, May 20, 2007 at 18:31 -0400:
>I'm coding an application using the kqueue facility, but
> I see that I can't handle open and read events. Is planned to
> implement these handlings in the future?. Also, which facility
> can I use to handle these ki
"Kevin Sanders" <[EMAIL PROTECTED]> writes:
> I'm trying to gain a better understanding of how kqueue's work from the
> driver side. I've managed to glean enough information from the source of
> other drivers, but I'm having a problem in my own kernel module when it is
> unloaded. Specifically, w
Robert Watson wrote:
My concern with this idea is that kqueues are not really intended to
provide an event stream, rather, notification of a condition. As writes
often come in batches, it's likely that by the time the kevent is
received, several writes will have occurred, but only a single ev
On Wed, 22 Nov 2006, Ivan Voras wrote:
From the kqueue(2) manual:
"""
EVFILT_VNODE Takes a file descriptor as the identifier and the events
to watch for in fflags, and returns when one or more of
the requested events occurs on the descriptor. The
e
On 11/23/06, Ivan Voras <[EMAIL PROTECTED]> wrote:
Vlad Galu wrote:
> My guess is that it won't be remarcably high. However, you can
> create those files, add them to your notification list and randomly
> write bytes to them, to see how your system performs. One more
> suggestion, I think it w
Vlad Galu wrote:
My guess is that it won't be remarcably high. However, you can
create those files, add them to your notification list and randomly
write bytes to them, to see how your system performs. One more
suggestion, I think it would be better if, in case you extend the
vnode API, you on
On 11/23/06, Ivan Voras <[EMAIL PROTECTED]> wrote:
Vlad Galu wrote:
> It seems to me you would have to propagate that info along the
> VOP_WRITE_POST->VFS_KNOTE_LOCKED->VN_KNOTE->knote() chain. Since
> knote() is generic and is used for all types of notifications, you can
> probably roll down
Vlad Galu wrote:
It seems to me you would have to propagate that info along the
VOP_WRITE_POST->VFS_KNOTE_LOCKED->VN_KNOTE->knote() chain. Since
knote() is generic and is used for all types of notifications, you can
probably roll down your own replacement and call it from VN_KNOTE. Of
course,
On 11/22/06, Ivan Voras <[EMAIL PROTECTED]> wrote:
>From the kqueue(2) manual:
"""
EVFILT_VNODE Takes a file descriptor as the identifier and the events
to watch for in fflags, and returns when one or more of
the requested events occurs on the descr
> "Alexander" == Alexander Leidinger <[EMAIL PROTECTED]> writes:
Alexander> Quoting John-Mark Gurney <[EMAIL PROTECTED]>
Alexander> (from Mon, 24 Jul 2006 14:36:42 -0700):
>> No one has written a d_kqfilter entry for tun... so, until someone
>> does, kqueue will not work on tun...
Alexander>
Quoting John-Mark Gurney <[EMAIL PROTECTED]> (from Mon, 24
Jul 2006 14:36:42 -0700):
No one has written a d_kqfilter entry for tun... so, until someone
does, kqueue will not work on tun...
Would you please come up with an entry for our ideas list
(http://www.freebsd.org/projects/ideas/) fo
David Gilbert wrote this message on Mon, Jul 24, 2006 at 15:19 -0400:
> I have some code that sets up a tunnel device and registers a kqueue
> filter for it ... ending roughly in:
>
> EV_SET(&kqev, cons->tunSocket, EVFILT_READ, EV_ADD | EV_ENABLE, 0, 0,
> &cons->fsdkq);
> kevent(fsd->kq, &kqev, 1
In the last episode (Apr 01), Vclav Haisman said:
> Dan Nelson wrote:
> > It's a kqueue bug, but a minor one. The problem is that the same
> > "flags" field is used to pass "actions" from the client, and return
> > status from the kernel. When you call kqueue with EV_ADD, the
> > kernel never cle
Vclav Haisman wrote this message on Sat, Apr 01, 2006 at 20:35 +0200:
> Dan Nelson wrote:
> > In the last episode (Apr 01), Vclav Haisman said:
> >> Hi,
> >> I have a little problem with kqueue/kevent. I am getting somewhat
> >> strange events from kevent(). The struct kevent's contents looks like
Dan Nelson wrote:
> In the last episode (Apr 01), Vclav Haisman said:
>> Hi,
>> I have a little problem with kqueue/kevent. I am getting somewhat
>> strange events from kevent(). The struct kevent's contents looks like this:
>>
>> kevent {.ident = 1, .filter = 0xfffe, .flags = 0x0001,
>>
In the last episode (Apr 01), Vclav Haisman said:
> Hi,
> I have a little problem with kqueue/kevent. I am getting somewhat
> strange events from kevent(). The struct kevent's contents looks like this:
>
> kevent {.ident = 1, .filter = 0xfffe, .flags = 0x0001,
> .fflags = 0x, .data
On Tue, 13 Dec 2005, John-Mark Gurney wrote:
Vaclav Haisman wrote this message on Wed, Dec 14, 2005 at 01:12 +0100:
On Tue, 13 Dec 2005, Vaclav Haisman wrote:
Is there equivalent of POLLERR for kqueue()? Or is EV_EOF the only thing?
I would like to use kqueue/kevent for sockets but error cond
Vaclav Haisman wrote this message on Wed, Dec 14, 2005 at 01:12 +0100:
> On Tue, 13 Dec 2005, Vaclav Haisman wrote:
>
> >Is there equivalent of POLLERR for kqueue()? Or is EV_EOF the only thing?
> >I would like to use kqueue/kevent for sockets but error condition
> >signaling is not clear to me
In the last episode (Mar 31), Matthew Luckie said:
> Does kqueue signal EOF on an ordinary file when there is nothing left
> to read?
>
> The code at http://www.wand.net.nz/~mjl12/kqfile.c.txt
>
> cc -Wall -o kqfile kqfile.c
> ./kqfile kqueue.c
>
> doesn't ever get EOF notification as far as i c
On Wed, 9 Feb 2005 10:51:36 -0500
Brian Fundakowski Feldman <[EMAIL PROTECTED]> wrote:
BFF> The LinuxThreads library seems to be the best-supported way. I don't think
BFF> that there should be legal/licensing issues using it.
Unfortunatelly, I can't use the LinuxThreads library, it simpl
On Wed, Feb 09, 2005 at 06:39:52PM +0300, Dmitry Agaphonov wrote:
> On Wed, 9 Feb 2005 09:49:24 -0500
> Brian Fundakowski Feldman <[EMAIL PROTECTED]> wrote:
>
> BFF> Since you're using user threads, not kernel threads, the kernel can only
> BFF> have one "object" (poll or select list, or k
On Wed, 9 Feb 2005 09:49:24 -0500
Brian Fundakowski Feldman <[EMAIL PROTECTED]> wrote:
BFF> Since you're using user threads, not kernel threads, the kernel can only
BFF> have one "object" (poll or select list, or kqueue file descriptor) to wait
BFF> upon at any given time. Since kqueues a
On Wed, Feb 09, 2005 at 05:36:25PM +0300, Dmitry Agaphonov wrote:
> Hello all,
>
> There's a server application that use non-bloking sockets with kqueue in
> its main thread and blocking I/O in two auxiliary threads. While watching
> the server in top(1), I've noticed that it is in the 'poll' sta
On Sat, 17 Jul 2004, Paul Querna wrote:
> I have a question about using KQueue() in multi-threaded situations. A
> couple months ago I wrote the KQueue support for Apache2/APR. I am now
> investigating a pseudo Event/Worker MPM to better handle KeepAlive
> Requests. (support for KQueue in Apache i
Brandon Erhart wrote this message on Thu, Apr 08, 2004 at 12:32 -0600:
> I am writing a web sucker downer (mirror) for a project on indexing the web
> (got myself a 1TB raid, just gonna d/l text ..). I am using the KQueue API
> in FreeBSD 4.9-REL to take care of watching over my sockets. I seem t
Jaromir Dolecek wrote:
> marius aamodt eriksen wrote:
> > in order to be able to preserve consistent semantics across poll,
> > select, and kqueue (EVFILT_READ), i propose the following change: on
> > EVFILT_READ, add an fflag NOTE_EOF which will return when the file
> > pointer *is* at the end of
> AFAIK yes for sockets, not for file descriptor (i.e. descriptor
> open to a file on filesystem). Would poll() give you read-availability
> event when on end of file on filesystem.
IIRC poll() is required to report that files are always readable.
(So tail -f can't use poll() to avoid looping.)
T
>> I think the difference is in the default behavior. When you're at
>> EOF, I know that poll() will give you a read-availability event, so
>> you'll read the EOF. Will kqueue?
> AFAIK yes for sockets, not for file descriptor (i.e. descriptor open
> to a file on filesystem). Would poll() give yo
Bill Studenmund wrote:
> I think the difference is in the default behavior. When you're at EOF, I
> know that poll() will give you a read-availability event, so you'll read
> the EOF. Will kqueue?
AFAIK yes for sockets, not for file descriptor (i.e. descriptor
open to a file on filesystem). Woul
marius aamodt eriksen wrote this message on Wed, Nov 12, 2003 at 14:06 -0500:
> > >right - the idea was to preserve existing semantics, while leaving the
> > >poll-like semantics optional.
> >
> > I'm not sure the "existing semantics" are anything more than a bug that
> > should be fixed.
>
> th
* Jason Thorpe <[EMAIL PROTECTED]> [031112 14:00]:
> On Nov 12, 2003, at 10:57 AM, marius aamodt eriksen wrote:
>
> >right - the idea was to preserve existing semantics, while leaving the
> >poll-like semantics optional.
>
> I'm not sure the "existing semantics" are anything more than a bug that
On Nov 12, 2003, at 10:57 AM, marius aamodt eriksen wrote:
right - the idea was to preserve existing semantics, while leaving the
poll-like semantics optional.
I'm not sure the "existing semantics" are anything more than a bug that
should be fixed.
-- Jason R. Thorpe <[EMAIL PROTECTED]>
* Jason Thorpe <[EMAIL PROTECTED]> [031112 13:54]:
> On Nov 12, 2003, at 10:40 AM, marius aamodt eriksen wrote:
>
> >correct - this is the difference, kqueue will not yield any event at
> >EOF.
>
> So, kqueue should simply be changed to report the event. I don't see
> any need for a separate E
On Nov 12, 2003, at 10:40 AM, marius aamodt eriksen wrote:
correct - this is the difference, kqueue will not yield any event at
EOF.
So, kqueue should simply be changed to report the event. I don't see
any need for a separate EOF flag. EOF can simply be determined as
normal in the kqueue case
* Bill Studenmund <[EMAIL PROTECTED]> [031112 12:27]:
> > I'm not sure I understand what is the exact issue.
>
> I'm only responding to the notes also.
>
> > Why would this be necessary or what does this exactly solve? AFAIK
> > poll() doesn't set any flags in this case neither, so I don't
> > s
On Wed, Nov 12, 2003 at 09:58:15AM +0100, Jaromir Dolecek wrote:
> marius aamodt eriksen wrote:
> > hi -
> >
> > in order to be able to preserve consistent semantics across poll,
> > select, and kqueue (EVFILT_READ), i propose the following change: on
> > EVFILT_READ, add an fflag NOTE_EOF which
marius aamodt eriksen wrote:
> hi -
>
> in order to be able to preserve consistent semantics across poll,
> select, and kqueue (EVFILT_READ), i propose the following change: on
> EVFILT_READ, add an fflag NOTE_EOF which will return when the file
> pointer *is* at the end of the file (effectively
On Monday 16 June 2003 11:39 am, Eric Jacobs wrote:
> On Mon, 16 Jun 2003 10:11:10 -0700
>
> Joshua Oreman <[EMAIL PROTECTED]> wrote:
> > On Mon, Jun 16, 2003 at 11:44:15AM +0100 or thereabouts, Tony Finch
seemed to write:
> > > Select doesn't work with files.
> >
> > Really? `man 2 select' says n
Joshua Oreman wrote:
> > >I would say, use select(2).
> > >Is there a reason this wouldn't work?
> >
> > Select doesn't work with files.
>
> Really? `man 2 select' says nothing about that. It just talks about
> 'file descriptors'. Now if it said 'socket descriptors' or 'non-file
> file descriptors
On Mon, 16 Jun 2003 10:11:10 -0700
Joshua Oreman <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 16, 2003 at 11:44:15AM +0100 or thereabouts, Tony Finch seemed to write:
> >
> > Select doesn't work with files.
>
> Really? `man 2 select' says nothing about that. It just talks about
> 'file descriptors'.
Select doesn't work with files.
Really? `man 2 select' says nothing about that. It just talks about
'file descriptors'. Now if it said 'socket descriptors' or 'non-file
file descriptors' I would understand, but I don't think that that statement
is implied by the man page. Is there something I'm
On Mon, Jun 16, 2003 at 11:44:15AM +0100 or thereabouts, Tony Finch seemed to write:
> Joshua Oreman <[EMAIL PROTECTED]> wrote:
> >On Sun, 15 Jun 2003, Matthew Hagerty wrote:
> >>
> >> I'm writing a little application that needs to watch a file that another
> >> process is writing to, think 'tail -
Tony Finch wrote:
> Joshua Oreman <[EMAIL PROTECTED]> wrote:
> >On Sun, 15 Jun 2003, Matthew Hagerty wrote:
> >>
> >> I'm writing a little application that needs to watch a file that another
> >> process is writing to, think 'tail -F'.
> >
> >I would say, use select(2).
> >Is there a reason this wo
Joshua Oreman <[EMAIL PROTECTED]> wrote:
>On Sun, 15 Jun 2003, Matthew Hagerty wrote:
>>
>> I'm writing a little application that needs to watch a file that another
>> process is writing to, think 'tail -F'.
>
>I would say, use select(2).
>Is there a reason this wouldn't work?
Select doesn't work
Drew Eckhardt wrote:
> In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> ux.org writes:
> >I would say, use select(2).
> >Is there a reason this wouldn't work?
>
> fd_set size...
That's inaccurate. In FreeBSD, select lists are permitted to be
arbitrarily large. See the select code itself for
In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
ux.org writes:
>I would say, use select(2).
>Is there a reason this wouldn't work?
fd_set size...
--
http://www.poohsticks.org/drew/";>Home Page
For those who do, no explanation is necessary.
For those who don't, no explanation is possible.
___
On Sun, Jun 15, 2003 at 09:50:24PM -0400 or thereabouts, Matthew Hagerty seemed to
write:
> > Joshua Oreman wrote:
> >> On Sun, 15 Jun 2003, Matthew Hagerty wrote:
> >>
> >>>I'm writing a little application that needs to watch a file that another
> >>>process is writing to, think 'tail -F'. kqueu
> Joshua Oreman wrote:
>> On Sun, 15 Jun 2003, Matthew Hagerty wrote:
>>
>>>I'm writing a little application that needs to watch a file that another
>>>process is writing to, think 'tail -F'. kqueue and kevent are going to
>>>do it for me on *BSD, but I'm also trying to support *cough* linux and
>
Robert Watson <[EMAIL PROTECTED]> 30 lines of wisdom included:
> I was recently told about a library named libevent from Niels Provos,
> which abstracts a variety of underlying event mechanisms behind a common
> API. You can learn a bit more about it here:
>
> http://www.monkey.org/~provos/lib
Matthew Hagerty wrote:
> I'm writing a little application that needs to watch a file that another
> process is writing to, think 'tail -F'. kqueue and kevent are going to do
> it for me on *BSD, but I'm also trying to support *cough* linux and other
> UN*X types OSes.
>
> >From what I can find on
Joshua Oreman wrote:
On Sun, 15 Jun 2003, Matthew Hagerty wrote:
I'm writing a little application that needs to watch a file that another
process is writing to, think 'tail -F'. kqueue and kevent are going to
do it for me on *BSD, but I'm also trying to support *cough* linux and
other UN*X types
On Sun, 15 Jun 2003, Matthew Hagerty wrote:
> I'm writing a little application that needs to watch a file that another
> process is writing to, think 'tail -F'. kqueue and kevent are going to
> do it for me on *BSD, but I'm also trying to support *cough* linux and
> other UN*X types OSes.
>
> >F
On Sun, 15 Jun 2003, Matthew Hagerty wrote:
> I'm writing a little application that needs to watch a file that another
> process is writing to, think 'tail -F'. kqueue and kevent are going to
> do it for me on *BSD, but I'm also trying to support *cough* linux and
> other UN*X types OSes.
>
>
yeah, I would like to implement it in scsi_target driver. I am using scsi HBA in
target to emulate as a sequential device. My userland application needs to be notified
of some events taking place in scsi_target driver.
Could you pls suggest me the best approach for this??
Thanks,
Jaya
Valen
Fri, May 30, 2003 at 12:14:50, jaya_bhat100 (Jayasheela Bhat) wrote about
"kqueue/kevent support in scsi device drivers":
JB> At present, kevent is supported for vnode, fifos, pipes and sockets, I believe.
JB> I would like to use kevent notification in scsi devices. But the drivers scsi_xx.c
On Wed, Sep 25, 2002 at 04:54:25PM +0300, vijay singh wrote:
> Hi, this is in no way related to the kqueue question asked below but to
> event notification mechanisms in general. I was wondering if there is
> some paper or design that talks about how such a facility could be
> provided in a Unix t
On Wed, Sep 25, 2002 at 10:35:06AM -0700, Terry Lambert wrote:
> The obvious objection to such changes is that the internals
> of the RPC library are sufficiently exposed that there is a
> near-dependency on the use of select; if you look at the "rpc"
> man page, for example, you will see, among
1 - 100 of 129 matches
Mail list logo
