From: Matthias R. <mri...@in...> - 2008-01-26 22:22:43
|
On 23.01.2008, at 22:30, I wrote: >>> I've had debug printfs showing, that indeed, there is some xine >>> code which >>> locks the >>> mutex twice. but everything is working. >> >> That's wrong, definitely. > > Interesting. Then, I'm gonna provide you (the list) with a trace of > this. Hi Matthias, :) Ok. Here's the trace of video_out_xv.c... open_plugin_2: -- LOCK -- xv_store_port_attribute -- LOCK/UNLOCK -- xv_check_capability -- xv_set_property -- LOCK/UNLOCK -- xv_update_XV_DOUBLE_BUFFER -- LOCK/UNLOCK -- UNLOCK open_plugin_2 is calling LOCK (resp XLockDisplay) and then calls various other functions which will again call LOCK. I don't know if this is a problem at all as XLockDisplay is supposed to be called several times by the same thread. But, it certainly would not hurt, if video_out_xv would call XLockDisplay (or the user supplied function) only once per x11 call. I will use a simple reference count in the LOCK macro to see, if my problems with deadlocks with the java binding go away. If this should be fixed, I can try to be the nit-picker and shuffle the LOCKs around a bit. cheers matthias |