KDE4 Development Critical Path

[Michel Hermier]

2006/3/15, Thiago Macieira <thiago at kde.org>:
> Michel Hermier wrote:
> >Is it possible to imagine to have both modes (thread/process) and
> >control it by environement variable ?
>
> I'd rather not.
>
> >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.
>
> Threads and debugging don't go together in the same sentence if that
> sentence also contains the word "gdb".
>
> Debugging threading problems is difficult, compounded by the fact that gdb
> has very little threading support. (Have you tried to have one thread
> keep running while all others keep stopped?)

Maybe, but I think it would be easier to do so, then try to
discover/guess which is the thread you have to debug, in the KIO pool,
then attach to it ...

I just thougth, do we really need to starts thread then, the code is
*bad* in the sence we prevent events to be send. Anyway does a KIO
really need to be blocking on some functions? it reduce the
responsivity of it. In all the case it should be feasable to make them
non blocking (even if it complicates them).

> >- 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).
>
> This can be done by starting a separate process out of the application,
> instead of out of kdeinit. KDE_FORK_IOSLAVES, I think.
>
> This means ioslaves aren't shared.

Slaves are shared, but does it really care in this case if there is
only 1 application.

> >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:
>
> I'd like to do that, but it's not high up in my priority list.
>
> The compromise I remember discussing was have D-Bus do the control
> channel, but use a separate socket for the data channel, thus avoiding
> the dbus-daemon be a man-in-the-middle.
>
> Then again, D-Bus already possesses direct app-to-app communication, so we
> could use that too. (I have not implemented that part of the protocol yet
> in QtDBus)
>
> >- 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.
>
> I don't see how D-Bus would help any of those tasks. Can you clarify?

The idea is to make the interfaces (or at least some) public, so that
any apps can interogate/configure the KIO, and don't make it a living
process dedicated to it's owner only.
It can do more and can talk with other apps, tell some of it's
internals states, what it has done ...