V_ONESHOT, or because the filehandle was closed by
> close(2).
>
> EV_DROPPED This flag is returned by the kernel if it is now about
> to drop the watch. After this flag has been received,
> no further events will occur on this
On 13.05.13 11:19, Eugen-Andrei Gavriloaie wrote:
> Regardless, it has all the ingredients for memory leaks and/or, the
> worst one, use of corpse pointers which are bound to crash the app. I
I earlier pointed out other things that prevent me from using kqueue as
a proper storage for use
to drop the watch. After this flag has been received,
no further events will occur on this watch.
This flag then makes it trivial to build a generic wrapper for kqueue
that can always manage its memory correctly.
a) at EV_ADD time, simply set flags |= EV_DROPWAT
On Wed, 15 May 2013 02:14:55 -0400
Julian Elischer wrote:
> I would suggest that one answer would be to create an extension to
> register a
> kevent to catch these events..
>
> (the knote_drop())
>
> The returned event could have all the appropriate information for the
> event being dropped..
ran into the problem needing EV_DROPWATCH/EV_DROPPED was
because I was trying to fix Perl's IO::KQueue.
IO::KQueue tries to wrap kqueue/kevent for Perl, allowing the userland
Perl code to store an arbitrary Perl data pointer in the udata field.
This data is reference-counted. Userland might let
to the problem needing EV_DROPWATCH/EV_DROPPED was
because I was trying to fix Perl's IO::KQueue.
IO::KQueue tries to wrap kqueue/kevent for Perl, allowing the userland
Perl code to store an arbitrary Perl data pointer in the udata field.
This data is reference-counted. Userland might let the ke
On Mon, 13 May 2013 11:10:44 -0700
Adrian Chadd wrote:
> ... also, want to code up a test implementation?
>
> And some stress testing cases to throw in the regression tree?
I already mostly fixed Perl's IO::KQueue wrapper to use this
hypothetical feature, I can easily provide
Just as a data point, I managed 50,000 + connections, at 5,000 + a
second, doing a gigabit + of traffic, mid-2000s, with the userland
management of all of the socket/disk FD stuff.
The biggest overhead at the time was actually the read/write
copyin/copyout, NOT the locking overhead of managing thi
ion tree?
>
> I already mostly fixed Perl's IO::KQueue wrapper to use this
> hypothetical feature, I can easily provide that somewhere for someone
> to test it against. I actually wrote that bit first, before I found
> such a feature did not exist.
>
> That would allo
ight, you can stub / inline out all of the wrapper
> functions in userland and translate them to straight system or library
> calls.
>
> Anyway. I'm all for making kqueue better. I just worry that adding
> little hacks here and there isn't the right way to do it. If you want
>
... also, want to code up a test implementation?
And some stress testing cases to throw in the regression tree?
I'll help shephard this in if this all works out.
thanks,
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/ma
On 13 May 2013 10:53, Paul LeoNerd wrote:
> [I'm not currently on the list so please forgive the manually-crafted
> reply]
>
>> I'm confused as to why this is still an issue. Sure, fix the kqueue
>> semantics and do it in a way that doesn't break backwards
&g
m all for making kqueue better. I just worry that adding
little hacks here and there isn't the right way to do it. If you want
to guarantee specific behaviours with kqueue, you should likely define
how it should work in its entirety and see if it will cause
architectural difficulties down the tr
[I'm not currently on the list so please forgive the manually-crafted
reply]
> I'm confused as to why this is still an issue. Sure, fix the kqueue
> semantics and do it in a way that doesn't break backwards
> compatibility.
I suggested that. Add a user->kernel flag
On Mon, 13 May 2013 18:19:43 +0300
Eugen-Andrei Gavriloaie wrote:
> I'm pretty sure this user data pointer is also breaking a well known
> pointer management paradigm, but I just can't remember which.
> Regardless, it has all the ingredients for memory leaks and/or, the
> worst one, use of corpse
-intrusivly solved at
lower levels. Seriously, if you truly believe that you can put the equal sign
between the complexity of the user space code and the wanted patch in kqueue
kernel side, than I simply shut up.
Besides, one of the important points in kq philosophy is simplifying things. I
e re-used. Especially in MT environments. Imagine one kqueue call
> taking place in thread A and another one in thread B. Both threads waiting
> for events.
.. so don't do that. I mean, you're already having to write your code
to _not_ touch FDs in other threads. I've done thi
your suggestion with FD index is a definite no-go. The FD
values are re-used. Especially in MT environments. Imagine one kqueue call
taking place in thread A and another one in thread B. Both threads waiting for
events.
When A does his magic, because of internal business rules, it decides to
... or you could just track the per-descriptor / per-object stuff in
userland, and use the FD/signal as an index into the state you need.
adding thread happiness on top of that is trivial.
Done/done.
Adrian
On 13 May 2013 08:19, Eugen-Andrei Gavriloaie wrote:
> Hello to all,
>
> I'm trying
Hello to all,
I'm trying to reply to this thread:
http://lists.freebsd.org/pipermail/freebsd-hackers/2010-November/033565.html
I also faced this very difficult task of tracking down the user data registered
into kq.
I end up having some "Tokens" instances which I never deallocate but always
re-
On 05.03.13 17:53, Alfred Perlstein wrote:
Alfred,
> I'm not sure if kqueue support this, however adding such a facility
> might be OK.
thanks for your reply. What would be the correct place to suggest such a
change?
> The only pain here is that it requires managing a doubly l
On 3/5/13 8:03 AM, Dirk Engling wrote:
Dear fellow FreeBSD hackers,
while writing a daemon that uses a kqueue to keep track of forked
processes and pipes to userland client code etc, I noticed a lack of
features to implement a proper shutdown without holding data redundantly.
When my daemon
Dear fellow FreeBSD hackers,
while writing a daemon that uses a kqueue to keep track of forked
processes and pipes to userland client code etc, I noticed a lack of
features to implement a proper shutdown without holding data redundantly.
When my daemon quits, I can not ask the kqueue for my
gt;> 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 thi
t;> >> >> > > 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
>> >&
; >> > > > Hi,
> >> >> > > >
> >> >> > > > Sorry about this repost but I'm confused about the responses I
> >> >> > > > received
> >> >> > > > in my last post so I'm looking
; >> > > > 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.
> >> >&
orry 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
> 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
: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 clarific
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 linuxfd_cr
t; 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 linuxfd
: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.
>> > > >
>> >
;
> > > > 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
> > &g
s 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 linuxfd_create/read, but was surprised that
> > > the
on.
> >
> > Specifically, I though I could use the kqueue timer as essentially a
> > "drop in" replacement for linuxfd_create/read, but was surprised that
> > the accuracy of the kqueue timer is much less than what I need for my
> > application.
>
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 essentiall
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
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 linuxfd_create/read, but was surprised that
;
I'm definitely not getting getting 20 millisecond timing with freebsd
kqueue which surprised me because I get it with linux
linuxfd_create/read using the same hardware.
--
Paul Albrecht
___
freebsd-hackers@freebsd.org mailing list
http://lists.f
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?
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 t
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 t
ting besides that I should
> also detect vnode changes and update max file size accordingly.
>
> >It should have been clear from my previous response.
>
> Please excuse me, I'm a bit new to this things...
Why do you use kqueue there at all ? Just read from stdin, and decide
that you
Hi,
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, I
often wait 21 milliseconds which is
Konstantin Belousov wrote:
So you mean this is just my false assumption that EOF _should_ occur on
stdin? And it actually occurs only if source is a process which can send
EOF?
'Source' cannot be a process. Read filter on pipes can return EV_EOF.
Read filter on vnodes (read: regular files) does
tation ?
> >
> >The vnode filter never returns EOF when current file position at the end
> >of file. It is documented that read filter returns when file offset if not
> >at the end of file, thats all. In fact, EV_EOF is returned on forced
> >unmount.
> >I do not
o not see a bug in kqueue.
On the other hand, your C code has at least two things that I cannot
understand. First, EV_EOF is output flag, it makes absolutely no sense
to set it in command.Second, it is mistery for me what do you check with
if (kev.flags>> 15 == 1) {
test.
n current file position at the end
of file. It is documented that read filter returns when file offset if not
at the end of file, thats all. In fact, EV_EOF is returned on forced unmount.
I do not see a bug in kqueue.
On the other hand, your C code has at least two things that I cannot
understand.
Hi all.
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/149857
This PR is rather old. I just had submitted new test case, now in plain c.
It doesn't work exactly like python version, but the result is the same:
> clang test.c
> cat test.c | ./a.out
-1 916 0 0 0
-1 0 32768 0 0
> ./a.out < test.
On Monday, March 05, 2012 1:12:55 pm Sergey Matveychuk wrote:
> Hi.
>
> I've met a problem with the subj. Could you help?
>
> I'm watching for a directory:
> EV_SET(kq_change_list, fd, EVFILT_VNODE,
> EV_ADD | EV_ENABLE | EV_ONESHOT,
> NOTE_DELETE | NOTE_WRITE | NOT
06.03.2012 0:57, Markiyan Kushnir wrote:
On 05.03.2012 20:12, Sergey Matveychuk wrote:
Hi.
I've met a problem with the subj. Could you help?
I'm watching for a directory:
EV_SET(kq_change_list, fd, EVFILT_VNODE,
EV_ADD | EV_ENABLE | EV_ONESHOT,
NOTE_DELETE | NOTE_WRITE | NOTE_EXTEND | NOTE_ATT
On 05.03.2012 20:12, Sergey Matveychuk wrote:
Hi.
I've met a problem with the subj. Could you help?
I'm watching for a directory:
EV_SET(kq_change_list, fd, EVFILT_VNODE,
EV_ADD | EV_ENABLE | EV_ONESHOT,
NOTE_DELETE | NOTE_WRITE | NOTE_EXTEND | NOTE_ATTRIB,
0, 0);
When the directory changed, I
Hi.
I've met a problem with the subj. Could you help?
I'm watching for a directory:
EV_SET(kq_change_list, fd, EVFILT_VNODE,
EV_ADD | EV_ENABLE | EV_ONESHOT,
NOTE_DELETE | NOTE_WRITE | NOTE_EXTEND | NOTE_ATTRIB,
0, 0);
When the directory changed, I read i
Hi.
I've met a problem with the subj. Could you help?
I'm watching for a directory:
EV_SET(kq_change_list, fd, EVFILT_VNODE,
EV_ADD | EV_ENABLE | EV_ONESHOT,
NOTE_DELETE | NOTE_WRITE | NOTE_EXTEND | NOTE_ATTRIB,
0, 0);
When the directory changed, I read i
On Wed, Feb 01, 2012 at 01:05:41AM +0100, Mateusz Guzik wrote:
> Hello,
>
> one pr ( http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/156423 )
> contains request to add kqueue support to /dev/klog.
>
> Assuming that this is a desirable feature, how about this patch (based
>
Hello,
one pr ( http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/156423 )
contains request to add kqueue support to /dev/klog.
Assuming that this is a desirable feature, how about this patch (based
on audit pipe's code):
http://student.agh.edu.pl/~mjguzik/patches/dev_klog-kqueue.patch
T
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
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 working only with filenames.
Matthias
__
EBADF)
There is problem between 21:30:06 and 21:30:36 timestamps.
Libevent received socket from Kqueue with EV_EOF flag when nginx has closed
connection.
There is 30 seconds timeout value in nginx config file.
On Fri, Aug 19, 2011 at 2:10 PM, Adrian Chadd wrote:
> I've not seen this happe
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
Hello!
I've got some interesting problem with my own server which use Libevent and
Kqueue.
Kqueue holds some sockets for a long time (while reading data) and gives it
back to application when another side closes connection.
I have server with FreeBSD 7.2 which serves several thousands req
nd is in the structure at the end
of that udata pointer.
Since you claim it to be so trivial then, I would like to ask you to
explain it. It should be quite a simple task:
---
Demonstrate me a program that, on receipt of -any- event out of the
kqueue file descriptor, can print the word "
is what people do? That was the thrust of my first
question - _is_ this what people do? I'm not experienced enough with
kqueue to know what is best practice here, and the documentation gives
no guidance. Can someone advise me?
---
Totally separate to that, if nobody has really thought of a so
my first
question - _is_ this what people do? I'm not experienced enough with
kqueue to know what is best practice here, and the documentation gives
no guidance. Can someone advise me?
---
Totally separate to that, if nobody has really thought of a solution to
this before, what are anyone's tho
On 11/15/10 10:38 AM, Paul LeoNerd Evans wrote:
On Mon, Nov 15, 2010 at 10:33:25AM -0800, Julian Elischer wrote:
it was provided for pretty much what you are using it for, so that
the userland caller could
easily associate the returning event with some private information
about the event.
This
event. However, the way it works is that it doesn't expose kevent()
> directly, instead it uses kevent to implement asynchronous I/O on a
> socket for example, and since it is logically managing the life cycle
> of a socket, it knows when the socket is closed and cleans up then.
Well,
ngrunning watches, but I don't think
> it sounds very convenient for a oneshot event; see the above example for
> justification.
For the above case, if you know an event is one shot, you should either
use EV_ONESHOT, or use a wrapper around the closure that clears the event
after the closu
On Mon, Nov 15, 2010 at 10:33:25AM -0800, Julian Elischer wrote:
> it was provided for pretty much what you are using it for, so that
> the userland caller could
> easily associate the returning event with some private information
> about the event.
This was indeed the impression I got. With refer
t think
it sounds very convenient for a oneshot event; see the above example for
justification.
Also it again begs my question, worth repeating here:
On Friday, November 12, 2010 1:40:00 pm Paul LeoNerd Evans wrote:
I had
thought the point of kqueue/kevent is the O(1) nature of it, which is
among
ches, but I don't think
it sounds very convenient for a oneshot event; see the above example for
justification.
Also it again begs my question, worth repeating here:
On Friday, November 12, 2010 1:40:00 pm Paul LeoNerd Evans wrote:
> I had
> thought the point of kqueue/kevent is the O(1) n
On Friday, November 12, 2010 1:40:00 pm Paul LeoNerd Evans wrote:
> I'm trying to build a high-level language wrapper around kqueue/kevent,
> specifically, a Perl wrapper.
>
> (In fact I am trying to fix this bug:
> http://rt.cpan.org/Public/Bug/Display.html?id=61481
> )
I'm trying to build a high-level language wrapper around kqueue/kevent,
specifically, a Perl wrapper.
(In fact I am trying to fix this bug:
http://rt.cpan.org/Public/Bug/Display.html?id=61481
)
My plan is to use the void *udata field of a kevent watcher to store a
pointer to some
- Original Message -
From: "Jeremy Chadwick" <[EMAIL PROTECTED]>
Can you change the polling method in lighttpd to use poll or select
instead of kqueue? This would help in determining if the problem is
with the daemon itself or the kevent system.
Yep already sched
) = 2 (0x2)
> > > kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
> 0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
> > > kevent(3,0x0,0,{0x7,EVFILT_WRITE,EV_EOF,54,0x832c,0x800d08080
> 0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) =
800d08080
> > 0x7,EVFILT_READ,EV_EOF,54,0x2a,0x800d08080},1024,0x0) = 2 (0x2)
> > -- and here --
> >
> > So two EOF are returrned for descriptor 7, and errno would be
> > ECONNRESET. The question is now, why isn't it oneshot?
>
> Ah one more thing. When
On 3/14/08, Vlad GALU <[EMAIL PROTECTED]> wrote:
> On 3/8/08, Vlad GALU <[EMAIL PROTECTED]> wrote:
> > On 3/8/08, Robert Watson <[EMAIL PROTECTED]> wrote:
> > > On Fri, 7 Mar 2008, Vlad GALU wrote:
> > >
> > >
> > > > I see an unusual symptom with one of our in-house applications. The
> m
On 3/8/08, Vlad GALU <[EMAIL PROTECTED]> wrote:
> On 3/8/08, Robert Watson <[EMAIL PROTECTED]> wrote:
> > On Fri, 7 Mar 2008, Vlad GALU wrote:
> >
> >
> > > I see an unusual symptom with one of our in-house applications. The main
> I/O
> > > loop calls kevent(), which in turn returns two eve
On 3/8/08, Robert Watson <[EMAIL PROTECTED]> wrote:
> On Fri, 7 Mar 2008, Vlad GALU wrote:
>
>
> > I see an unusual symptom with one of our in-house applications. The main I/O
> > loop calls kevent(), which in turn returns two events with EV_EOF error
> set,
> > always for the same descriptors (
On Fri, 7 Mar 2008, Vlad GALU wrote:
I see an unusual symptom with one of our in-house applications. The main I/O
loop calls kevent(), which in turn returns two events with EV_EOF error set,
always for the same descriptors (they're both socket descriptors). As the
man page is not pretty clear
On 3/7/08, Julian Elischer <[EMAIL PROTECTED]> wrote:
> Vlad GALU wrote:
> > On 3/7/08, Julian Elischer <[EMAIL PROTECTED]> wrote:
> >> Vlad GALU wrote:
> >> >I see an unusual symptom with one of our in-house applications. The
> >> > main I/O loop calls kevent(), which in turn returns two
Vlad GALU wrote:
On 3/7/08, Julian Elischer <[EMAIL PROTECTED]> wrote:
Vlad GALU wrote:
>I see an unusual symptom with one of our in-house applications. The
> main I/O loop calls kevent(), which in turn returns two events with
> EV_EOF error set, always for the same descriptors (they're b
On 3/7/08, Julian Elischer <[EMAIL PROTECTED]> wrote:
> Vlad GALU wrote:
> >I see an unusual symptom with one of our in-house applications. The
> > main I/O loop calls kevent(), which in turn returns two events with
> > EV_EOF error set, always for the same descriptors (they're both socket
>
Vlad GALU wrote:
I see an unusual symptom with one of our in-house applications. The
main I/O loop calls kevent(), which in turn returns two events with
EV_EOF error set, always for the same descriptors (they're both socket
descriptors). As the man page is not pretty clear about it and I don't
I see an unusual symptom with one of our in-house applications. The
main I/O loop calls kevent(), which in turn returns two events with
EV_EOF error set, always for the same descriptors (they're both socket
descriptors). As the man page is not pretty clear about it and I don't
have my UNP copy a
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
t; in the driver doesn't support select and poll at the same time - which I
> guess lines up with the reported failure
> with USB serial.
>
> Does kqueue work with USB for example? How about an AIO request to read
&
itations) which I've
elided.
I think the most telling thing is probably that drivers need to provide
support and that a single mechanism
in the driver doesn't support select and poll at the same time - which I
guess lines up with the reported failure
with USB serial.
Does kqueue
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 aut
ckends compiled into this binary of libev
and also recommended for this platform. This set is often smaller
than the one returned by |ev_supported_backends|, as for example
kqueue is broken on most BSDs and will not be autodetected unless
you explicitly request it (assuming you know what you are
> > 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
this platform. This set is often smaller
than the one returned by |ev_supported_backends|, as for example
kqueue is broken on most BSDs and will not be autodetected unless
you explicitly request it (assuming you know what you are doing).
and
|EVBACKEND_KQUEUE| (value 8, most BSD clones
is often smaller
than the one returned by |ev_supported_backends|, as for example
kqueue is broken on most BSDs and will not be autodetected unless
you explicitly request it (assuming you know what you are doing).
and
|EVBACKEND_KQUEUE| (value 8, most BSD clones)
Kqueue deserves
maller
> than the one returned by |ev_supported_backends|, as for example
> kqueue is broken on most BSDs and will not be autodetected unless
> you explicitly request it (assuming you know what you are doing).
>
> and
>
> |EVBACKEND_KQUEUE| (value 8, most BSD clones)
>
> Kqu
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
>
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 so
than the one returned by |ev_supported_backends|, as for example
kqueue is broken on most BSDs and will not be autodetected unless
you explicitly request it (assuming you know what you are doing).
and
|EVBACKEND_KQUEUE| (value 8, most BSD clones)
Kqueue deserves special mention, as at the
Karsten Behrmann wrote:
> Heya,
>
>> Does unionfs work with kqueue? When I run `tail -f` on a file residing
>> on unionfs with cd9660 underneeth and md+ufs over it, it doesn't detect
>> changes. The changes are immediately visible, just not with tail -f.
>
> Hm
1 - 100 of 294 matches
Mail list logo
