Re: kqueue giant-locking (&kq_Giant, locking)
From: Garrett Wollman (wollman_at_khavrinen.lcs.mit.edu)
Date: 04/17/04
- Previous message: Devon H. O'Dell: "Re: [patch] lockf(3) user-exploitable kernel panic"
- In reply to: Brian Fundakowski Feldman: "kqueue giant-locking (&kq_Giant, locking)"
- Next in thread: Brian F. Feldman: "Re: kqueue giant-locking (&kq_Giant, locking)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 16 Apr 2004 22:53:48 -0400 (EDT) To: green@freebsd.org
In article <200404170212.i3H2Cg8n031749@green.homeunix.org> you write:
>1. The recursion has been removed from kqueue. This means kqueues cannot be
> added to other kqueues for EVFILT_READ -- yes, that ability has been
> around since r1.1 of kern_event.c,
Actually, I'm fairly certain that Jonathan considered this to be a
fairly important property of kqueue and his papers do mention it.
It was done that way specifically to allow a kqueue to be included in
some larger application's event polling loop without needing to know
how it was implemented.
-GAWollman
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
- Previous message: Devon H. O'Dell: "Re: [patch] lockf(3) user-exploitable kernel panic"
- In reply to: Brian Fundakowski Feldman: "kqueue giant-locking (&kq_Giant, locking)"
- Next in thread: Brian F. Feldman: "Re: kqueue giant-locking (&kq_Giant, locking)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|