| Markus E L 2007-08-27, 4:30 am |
|
Rayiner Hashem wrote:
> "It doesn't work exactly the way I'm used to, wah, wah, wah" is not an
> legitimate argument.
Is "I don't want to modify the language run time?". As I understand
the fork()-trick it's all about getting some kind of concurrency with
a high "initial" bandwith of communication to the subsidiary thread
(at fork time)[1] without having to modify the language runtime,
libraries and compiler[2]. [1] is something you don't get with
starting new programs (which is what CreateProcess does AFAIR) and [2]
is something which you don't get if you use any explicit file or
memory mappping mechanisms.
This is all not about something really profound and
fundamental. Basically it's about a trick, a very neat trick. And a
trick that doesn't work efficiently on Windows. I think from that
point on it's useless to argue either, that "it works on windows too"
or "the trick is useless, because you can instead ...". It doesn't
work efficiently on windows and the requirement is that one doesn't
want to use another method (see [2]).
My impression is that your opposition is partially fueled by a
conviction that this somehow is a slander on Windows. I don't think
so: It's just recognition of the fact that Win32 and POSIX are two
different worlds and that a mapping between them is only partially
possible. If it helps: Windows had efficient kernel space threads
earlier than most of the common Unix platforms AFAIR (and Unix people
were convinced that they don't need threads so much because they have
parallelism by fork() -- so one thing is actually a substitute for the
other, as afar as concepts go, but cannot be mapped on each other in
the the sense of a drop in replacement or implementing fork() over
threads or threads over fork()).
Regards -- Markus
PS: Do you read on c.l.f -- if yes, I'd prefer the thread to continue
there. If at all.
|