Greetings... a patch I would like your comments on...

[Randall Stewart]

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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org 
> "
>

------------------------------
Randall Stewart
803-317-4952 (cell)
803-345-0391(direct)