[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 EV_DROPWATCH which, if present, causes kernel to send back to userland events with the kernel->user flag EV_DROPPING any time it drops the pointer. Then trivially userland just has to set that flag on all its events to the kernel, and remember to send those events back to userland when it does in fact drop them. These events can be trivially created from the knote_drop() function: http://fxr.watson.org/fxr/source/kern/kern_event.c#L2127 because that's called everywhere in the kernel that actually drops the watch. Which brings me onto the main reason why: It becomes a lot simpler to write userland code. When I wrote the original idea 3 years ago, it was after some research into what reasons would drop these watches in the kernel. By having the kernel tell userland, that future-proofs it a lot better. To further answer the threading questions: Having the locking point decided by the kernel and the event reflected back up to userland still with the pointer that kernel had simplifies all this locking. Now, userland doesn't have to contend on a Big Structure Lock around whatever data structure it uses to store all this information. It allows less userland contention. It's fully back-compatible, because all it does is adds a new user->kernel flag, that if the userland didn't know about, wouldn't set, and no behaviour is changed. If the flag -is- set then userland simply starts receiving a few extra events, or has another bit flag set on the events it was already receiving. Finally: I feel quite sure this feature is implementable in ballpark-50 lines of kernel-side code. I'd half-bet the documentation would be longer than that. It is truely a tiny addition of behaviour to export information the kernel already knows (namely: that it is calling knote_drop()). I can't see any objection to it. I'm quite sure more words and objection have been spent arguing it back and forth than it would have taken just to implement it initially. -- Paul "LeoNerd" Evans leon...@leonerd.org.uk ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/
signature.asc
Description: PGP signature
