KDE4 Development Critical Path

[Michel Hermier]

2006/3/15, Guillaume Laurent <glaurent at telegraph-road.org>:
> Michael Brade wrote:
> > On Wednesday 15 March 2006 10:13, Ingo Klöcker wrote:
> >
> >> One important reason pro processes is that a crash in a kioslave process
> >> doesn't kill the whole application. This advantage of separate
> >> processes over threads should not be underestimated.
> >>
> > That's actually a very good point! I will immediately remove all my thoughts
> > about threads :-)
> >
> Threads and processes are not equivalent and have different usages, and
> kioslaves are much more a job for processes than threads, IMHO. All they
> need to do is to feed back a data stream to their parent, they do not
> need to access the parent's data, and they are relatively short lived.
> Turning kioslaves into threads would be a huge mistake. I can't see any
> added benefit (not even performance), but it will introduce endless
> reliability problems.

Is it possible to imagine to have both modes (thread/process) and
control it by environement variable ?
I see 2 avantages to have it in threads, while I agree by default it
should go to a different process :
- help debuging in 2 ways: enabling the usage of regular debuging
tools (without great knowledge for the end users), enable *live*
debugging without disturbing the *production* system.
- don't need to start the whole kde backend if you intend to use a
single app of the KDE (this argument is weak, but can help to run
small/single apps on weak on ressources systems).

Another thing, wouldn't it be to make the kio use the D-BUS system to
control the IO ? I know some peopole are against it and prefer the
handmade protocol, but I think we can take some advantages of using
the D-BUS, and add some functionnallity to the KIO processes, like:
- monitoring the KIOs and get some informations/statistics about them.
- duplicating stream from a single KIOs (duplication of live /*video*/
stream by example)
- more maintainable/easy way to control/configure the KIO's beahaviour.