Severe thumbnail problems

[Martijn Klingens]

On Sunday 22 December 2002 11:37, Malte Starostik wrote:
> As I understand George, he has disabled the "Start aRts soundserver on KDE
> startup" option in kcontrol. Now this option clearly states what it does:
> it starts aRts on KDE startup if enabled. Disabling it does not imply that
> artsd is never started.
> So would I have to check for that option in konq_sound (the ioslave is not
> involved here) and just don't do anything if it's disabled? This might fix
> the current problem but it would turn the option into "Start aRts
> soundserver on KDE startup or for A/V file prelistening/views" :-)

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.

-- 
Martijn