[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Disk usage optimizations
From:       Esben Mose Hansen <kde () mosehansen ! dk>
Date:       2005-02-25 23:11:04
Message-ID: 200502260010.04471.kde () mosehansen ! dk
[Download RAW message or body]

On Friday 2005-02-25 22:03, Manuel Amador wrote:

> > Being able to fork all the time is so nice, so efficient and so much
> > /cleaner/ than execv or threads. All IMHO, of course.
>
> the word "fork" in that context has a different meaning.  We used "fork"
> as the name for the libc call fork(2).  You meant fork as in "we're
> forking this project to do our own stuff".

Eh no. I meant pid_t fork(); Though forking projects are a cool feature, it's 
seldom efficient, and being cleaner than execv would be nonsense :P Earlier I 
expressed that I hoped that any windows port would be a forked project rather 
than incorporated in main KDE. I hope that's all cleared up now :)

>
> Or I misunderstood.  But fork(2) rules!

Indeed. It's the only reasonable way to do any uniprocessor multitasking.

>
> What is clear is that by porting to Windows you will be able to develop
> apps without having to deal with the Win32 API.  And by porting to
> Windows, a great deal of bugs may be squashed just because of the fact
> that the porters will pore over large amounts of code.

Yes, but such could be backported to the 'nix KDE.

>
> So, the windows port could actually be beneficial for KDE, at least in
> that sense.

Yes. I just don't want commits to 'nix KDE turned down because "forking 3 
times is too slow in windows" or "forking from the event thread is too slow 
in windows". That disadvantage would be greater than the benefits in the long 
run, IMHO.

-- 
regards. Esben
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]