On Jan 22, 2010, at 8:04 AM, Ivan Voras wrote:
On 01/22/10 16:55, Randall Stewart wrote:
If I read the comment at filt_umtxattach() correctly, in the best
case
you would need an extension to the kevent structure to add more
fields
like data & udata (for passing values back and forth between
userland
and kernel). I agree with this - it would be very convenient for
some
future purposes (like file modification notification) if the kernel
filter could both accept and return a struct of data from/to the
userland.
Yeah, more arguments inside the kevent would allow me to add the
COND_CV_WAIT* where a lock and condition are passed
in as well... But I was hesitant to add more than was already there
since doing
so would cause ABI ripples that I did not want to face.
Yes, this should be done carefully; just adding more "data" and
"udata" fields will postpone the problem to when someone else needs
one more field to make his idea working - a memory blob should
probably be the way to go.
I plan on committing this to head if I don't get strong "you idiot
you
did it wrong" comments ;-)
Hmmm, something just occured to me: why did you name the event /
filter "EVFILT_KQUEUE"? Why not something like "EVFILT_UMTX" or
"EVFLT_COND"?
Yep.. has I am just sitting down to write my "super crusher" test case
I realize .. what was I smoking when I said
EVFILT_KQUEUE.. thats got to change.. I think maybe EVFILT_UMTX_COND
is best.. UMTX might let you think
you could send in a lock or something else..
You said you didn't make the actual connection to the userland
pthead_* API yet - how did you test it?
Actually I am using just raw umtx itself. For just quick testing a
_thr_umtx_wake((u_long *)addr, count);
Works..
Or one can even dig in and do the actual syscall..
_umtx_op().. but that requires a lot more arguments ;-)
I need to think on integrating it into pthread*.. but we actully
have at work our own mutex stuff for apps that is in user space and is
a bit faster (quite a bit)... and it uses the umtx stuff directly ;-)
R
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org
"
------------------------------
Randall Stewart
803-317-4952 (cell)
803-345-0391(direct)
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
