The vnode lock operations currently work on a rw lock located inside the
vnode. I propose to move this lock into the file system node.
This place is more logical as we lock a file system node and not a vnode.
This becomes clear if we think of a file system where one file system node
is attached
Can anyone tell me why, exactly, we shouldn't remove bound AF_LOCAL
sockets from the filesystem on last close?
Well, I wouldn't expect it to be easy; it means that every AF_LOCAL
socket needs to keep track of its directory,name pair. This leaves
open the question of what to do if it has
But I agree that if leaving the sockets around permits no interesting
feature whatsoever (i.e. it doesn't even serve for SO_REUSEADDR),
I've been trying to think of any such feature since this discussion
started. So far i've failed.
it very well could be a design or implementation bug,
I
A reason might be that every other system behaves the same way and
being different will just lead to non-portable code.
Non-portable *how*? What exactly would happen?
I don't know, and if you've got an argument that code written for
either behavior will be ok both places I don't have a
OK this is from kqueue man page:
kevent() returns the number of events placed in the eventlist, up to
the value given by nevents
What I find confusing is that kevent() returns int data type, however
the length of eventlist given by nevents can be up to size_t.
Suppose you have more than INT_MAX
On Sat, 26 Jun 2010 14:04:18 +0100
Sad Clouds cryintotheblue...@googlemail.com wrote:
What I find confusing is that kevent() returns int data type, however
the length of eventlist given by nevents can be up to size_t.
Suppose you have more than INT_MAX events in kqueue, what are the
On Sat, Jun 26, 2010 at 10:39:27AM +0200, Juergen Hannken-Illjes wrote:
The vnode lock operations currently work on a rw lock located inside the
vnode. I propose to move this lock into the file system node.
This place is more logical as we lock a file system node and not a vnode.
This
