On Fri, 27 Feb 2009, Igor M. Liplianin wrote: > 01/02: dm1105: not demuxing from interrupt context. > http://mercurial.intuxication.org/hg/v4l-dvb-commits?cmd=changeset;node=6faf0753950b I'm not sure if you considered this, but the default work queue is multi-threaded with a kernel thread for each CPU. This means that if the IRQ handler calls schedule_work() while your work function is running then you can get a second copy running of your work function running at the same time. It doesn't look like your work function uses atomit_t or locking, so I'm guessing it's not safe to run concurrently. For the pluto2 patch, I created a single threaded work queue. This avoids the concurrency problem and it's not like the demuxer can run in parallel anyway. Having your own work queue also means that you don't have to worry about latency from whatever other tasks might be in the default work queue. Also consider that the work function is queued mutliple times before it runs, it will only run once. I.e. queuing a work func that's already in the queue does nothing (one the function starts to run, it's no longer in the queue and can be added again before it's finished). The pluto2 patch I posted didn't take this into account, but I've since fixed it. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
