G
Guest
Hi. I was just wondering if you can fork a process in .NET like you would in C
Thank
Jenna
Thank
Jenna
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
J
Jon Skeet [C# MVP]
JennaS said:Hi. I was just wondering if you can fork a process in .NET like you would in C.
I don't believe so - but the usual solution to the problem it normally
addresses is to use threads in .NET.
M
Miha Markic [MVP C#]
Hi,
As Jon said, and afaik windows doesn't have fork feature - instead you
should use threads.
As Jon said, and afaik windows doesn't have fork feature - instead you
should use threads.
T
Tom Dacon
Forgive me for going off on a tangent with this post here, but I'm just
wondering...
I've done a fair bit of Unix programming in my long and checkered past, and
I've used fork() once in a while. I've done multitasking in mainframe and
micro operating systems, even written OS task schedulers, and used threads
in MS programming, particularly in .Net where they're almost trivially easy.
Is there anyone besides me that thinks that the fork business in Unix, both
from the conceptual viewpoint and the implementation viewpoint, is truly
bizarre?
Just asking...inquiring minds want to know.
Tom Dacon
Dacon Software Consulting
wondering...
I've done a fair bit of Unix programming in my long and checkered past, and
I've used fork() once in a while. I've done multitasking in mainframe and
micro operating systems, even written OS task schedulers, and used threads
in MS programming, particularly in .Net where they're almost trivially easy.
Is there anyone besides me that thinks that the fork business in Unix, both
from the conceptual viewpoint and the implementation viewpoint, is truly
bizarre?
Just asking...inquiring minds want to know.
Tom Dacon
Dacon Software Consulting
Miha Markic said:Hi,
As Jon said, and afaik windows doesn't have fork feature - instead you
should use threads.
--
Miha Markic [MVP C#] - RightHand .NET consulting & development
miha at rthand com
www.rthand.com
wouldJennaS said:Hi. I was just wondering if you can fork a process in .NET like you
in C.Thanks
Jenna
J
John Vottero
Tom Dacon said:Forgive me for going off on a tangent with this post here, but I'm just
wondering...
I've done a fair bit of Unix programming in my long and checkered past, and
I've used fork() once in a while. I've done multitasking in mainframe and
micro operating systems, even written OS task schedulers, and used threads
in MS programming, particularly in .Net where they're almost trivially easy.
Is there anyone besides me that thinks that the fork business in Unix, both
from the conceptual viewpoint and the implementation viewpoint, is truly
bizarre?
Just asking...inquiring minds want to know.
You're not the only one that thinks that fork is forked! Every time I see
this question I think "Why would you want it???".
T
Tom Dacon
You're not the only one that thinks that fork is forked! Every time I see
Well, there are certainly times that you want to create and start a child
process. For instance, a TCP/IP server listens on a port for an incoming
request, and might spawn a child process to handle each session. That way
multiple sessions can be underway, and nobody has to wait for some other
session's transaction to finish (other than the inevitable fact that the
session processes are probably sharing a physical CPU).
What I think is weird is the way that fork() is designed to work. It just
seems downright strange that the process you make the fork() call in sort of
clones itself, and each process (the originator and the child) continue to
run in the same code path. Fork() returns a process id (a PID) and the
caller stores it in a variable. Both processes continue in the same code
path, both have access to the same variables, but the returned process ID is
actually stored in only one of the two processes, so the code looks
something like:
int childpid = 0;
childpid = fork();
if ( childpid > 0 ) {
// well, I'm still in the originating process, since the childpid was
// stored in my address space, so I guess I'll loop around and listen
// on the incoming port again...
}
else if ( childpid == 0 ) {
// well, I'm running in the new child process, because the childpid
// was stored in the originating process's address space, not in mine,
// so I guess I'll go off and process the requests for this session...
}
else if ( childpid < 0 ) {
// well, here I am, still in the originating process, but the fork
failed.
}
I guess there's nothing wrong with it, once you're used to it, but in my
opinion it makes for some odd-looking code. It's like the code has a bipolar
disorder. Still, a Unix weenie who had never seen any other way of doing
things would probably think this is just the natural way something like this
should be done. Thankfully, I haven't had to do any Unix programming for a
few years now, and with luck things will stay that way.
Regards,
Tom Dacon
this question I think "Why would you want it???".
Well, there are certainly times that you want to create and start a child
process. For instance, a TCP/IP server listens on a port for an incoming
request, and might spawn a child process to handle each session. That way
multiple sessions can be underway, and nobody has to wait for some other
session's transaction to finish (other than the inevitable fact that the
session processes are probably sharing a physical CPU).
What I think is weird is the way that fork() is designed to work. It just
seems downright strange that the process you make the fork() call in sort of
clones itself, and each process (the originator and the child) continue to
run in the same code path. Fork() returns a process id (a PID) and the
caller stores it in a variable. Both processes continue in the same code
path, both have access to the same variables, but the returned process ID is
actually stored in only one of the two processes, so the code looks
something like:
int childpid = 0;
childpid = fork();
if ( childpid > 0 ) {
// well, I'm still in the originating process, since the childpid was
// stored in my address space, so I guess I'll loop around and listen
// on the incoming port again...
}
else if ( childpid == 0 ) {
// well, I'm running in the new child process, because the childpid
// was stored in the originating process's address space, not in mine,
// so I guess I'll go off and process the requests for this session...
}
else if ( childpid < 0 ) {
// well, here I am, still in the originating process, but the fork
failed.
}
I guess there's nothing wrong with it, once you're used to it, but in my
opinion it makes for some odd-looking code. It's like the code has a bipolar
disorder. Still, a Unix weenie who had never seen any other way of doing
things would probably think this is just the natural way something like this
should be done. Thankfully, I haven't had to do any Unix programming for a
few years now, and with luck things will stay that way.
Regards,
Tom Dacon
M
Miha Markic [MVP C#]
Hi guys,
I prefer threads approach - it seems more clean and isolated to me.
Tom Dacon said:Well, there are certainly times that you want to create and start a child
process. For instance, a TCP/IP server listens on a port for an incoming
request, and might spawn a child process to handle each session. That way
multiple sessions can be underway, and nobody has to wait for some other
session's transaction to finish (other than the inevitable fact that the
session processes are probably sharing a physical CPU).
I prefer threads approach - it seems more clean and isolated to me.
S
Stu Smith
Tom Dacon said:Well, there are certainly times that you want to create and start a child
process. For instance, a TCP/IP server listens on a port for an incoming
request, and might spawn a child process to handle each session. That way
multiple sessions can be underway, and nobody has to wait for some other
session's transaction to finish (other than the inevitable fact that the
session processes are probably sharing a physical CPU).
I have an idea, feel free to shoot it down:
It could be that fork is designed more for parallelism, rather than worker
style. In that case, having the state immediately available (rather than
having to store it out into state variables prior to jumping to the thread
start) makes some sort of sense:
Here's what I want to do:
SomeVector a, b, c;
for( int i = 0; i < 1000; ++i )
{
a = b + c;
}
but I could do it across my two processors:
int childpid = 0;
childpid = fork();
SomeVector a, b, c;
if ( childpid > 0 ) {
for( int i = 0; i < 500; ++i )
{
a = b + c;
}
waitpid(child);
}
else if ( childpid == 0 ) {
for( int i = 500; i < 1000; ++i )
{
a = b + c;
}
exit();
}
(And I've probably got my system calls wrong, and an off-by-one error, and
no error-checking, etc).
Just an idea.
Stu
T
Tom Dacon
It could be that fork is designed more for parallelism, rather than worker
style. In that case, having the state immediately available (rather than
having to store it out into state variables prior to jumping to the thread
start) makes some sort of sense:
That's a good observation, Stu. I think if there's anything to say in favor
of the fork() technique, it's that the new process starts off with a
complete snapshot of all the data that's in scope for the initiating
process. So there's no need to go through the work of packaging up
information and passing it off to the new process. That's not so bad, I
guess. So unless we hear from some fierce Unix wallah who has an impassioned
defense to present, I'm prepared to leave it at that.
Best regards,
Tom Dacon
Dacon Software Consulting
T
Tom Dacon
I prefer threads approach - it seems more clean and isolated to me.
To me too. As well as more intuitive.
Tom Dacon
Dacon Software Consulting
To me too. As well as more intuitive.
Tom Dacon
Dacon Software Consulting