On 27 февраля 2009, "Igor M. Liplianin" <liplianin@xxxxxx> wrote: > 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=6 > >faf0753950b > > 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. I'll return to this :) But it complicates things more and more :( -- Igor M. Liplianin Microsoft Windows Free Zone - Linux used for all Computing Tasks -- 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
