Re: Why not to split gmc and other gnome applications into threads?

> I think it would be better to have each gmc window as a separate process.

I'm not sure if thats the best method to do it.  If you fill up your
process table you'll be in trouble.  (depending on the state of the
machine)  Using light weight processes (ie threads) will be a lot better
since you don't have the overhead that a regular process has.

Is something wrong with using pthreads?  What makes this difficult is that
this is a desktop project for all Unices.  Is there some sort of emulation
library that will give a consistent interface to threads regardless of OS?

> Ok that would be a little bit more expensive, but it would pay. They could

Just a bit. :-)

> then communicate with some back-end that coordinated them. Then any app
> would be able to connect to that back-end and ask it to fire up a
> gmc-window, or icon-box (As in the root-window case) inside some of (its)
> (existing) X window... That, I think would be much easier to implement,
> since it would only requere to replace all code in gmc that handles the
> creation of a new window, with some backend-communication code, and to
> create a back-end.

It would be okay for now but you'll definitely have people complaining.
Besides, gmc is going out in favor of a new filemanager that is in the


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]