Severe thumbnail problems
malte at kde.org
Sun Dec 22 17:51:31 GMT 2002
On Sunday 22 December 2002 12:50, Martijn Klingens wrote:
> On Sunday 22 December 2002 11:37, Malte Starostik wrote:
> Artsd has some safeguards against excessive CPU usage anyway. The main
> problem as I see it from this thread is that there are more instances of
> artsd. IIRC there should be only one, which is supposed to be reused for
> subsequent tasks, so the CPU monitoring can also be done properly by this
> one and only daemon. See also the earlier threads on artsd's realtime
> priority btw.
> Since the thumbnail code fires up a few slaves at the same time I think
> this is a race condition where no running artsd is detected and 10 slaves
> are each given their own artsd instance. I don't know where the check for a
> running artsd is done now, but most robust to me would probably be a single
> entry point in e.g. klauncher which makes sure no second artsd is started
> (or a kded module). Good enough for this case, and a lot easier to write,
> but not avoid races between different applications, is to have the check in
> the thumbnail generating code, just before spawning the slave. Downside of
> this is that the thumb code explicitly needs to know whether a slave is
> arts-using or not.
As mentioned before, the A/V previews do *not* use the kio_thumbnail.
libkonq/konq_sound.cc is responsible for them and there is only one instance
of konq_sound at a time per konqueror view. And when the view loses focus,
this instance stops. The only chance of a race caused here is if you have
multiple views and move around with the pointer very fast between them, from
one A/V file to another.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
More information about the kde-core-devel