On Mon, March 5, 2007 11:19, Johannes Stezenbach wrote: > On Mon, Mar 05, 2007 at 01:58:14AM +0100, Oliver Endriss wrote: >> Simon Arlott wrote: >> > Is any part of the patch going to be applied? I mentioned this >> > problem in September last year and it looks like it's existed for >> > years (the semaphore locking did the same thing). >> >> Well, I hoped that someone more familiar with the demuxer stuff would >> comment on the patch. I am not very happy about using non-interruptible >> lock operations... Why? If there are deadlocks these should be fixed, not ignored. >> Anyway, I'll apply the patch to HG master if you submit an updated patch: >> - Please add a line of comment to each mutex_lock() stating _why_ the >> non-interruptible lock has to be used at this place. What's the point of doing that? > IMHO using mutex_lock_interruptible() is almost always wrong. > > The only use it has in dvb-core is to recover from locking bugs -- > if it deadlocks you can Ctrl-C out of it > (instead of being left with a non-killable program -> reboot). This is what lockdep is for. > But with mutex_lock_interruptible() it's easy to introduce > signal handling bugs, which Simon confirmed to exist. It's also easy to find examples of people needing to rmmod/modprobe because dvr0 started returning -EBUSY on open() after they closed something. > Fixing those up without reverting to mutex_lock() way might > be possible, but is more difficult. It'd introduce lot of unneccessary -ERESTARTSYS, just to avoid the possiblity of waiting on mutex_lock for a few msecs. -- Simon Arlott _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
