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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to