Severe thumbnail problems

[Malte Starostik]

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.

-Malte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-multimedia/attachments/20021222/f7334a22/attachment.sig>