Hi. I was just wondering if you can fork a process in .NET like you would in C
Thank
Jenna
Thank
Jenna
-
-
Re: Forking processes in .NET
JennaS <anonymous@disc ussions.microso ft.com> wrote:[color=blue]
> Hi. I was just wondering if you can fork a process in .NET like you would in C.[/color]
I don't believe so - but the usual solution to the problem it normally
addresses is to use threads in .NET.
--
Jon Skeet - <skeet@pobox.co m>
If replying to the group, please do not mail me too
-
Re: Forking processes in .NET
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
"JennaS" <anonymous@disc ussions.microso ft.com> wrote in message
news:95F9EE1B-6C61-4741-9584-3097194AC8F2@mi crosoft.com...[color=blue]
> Hi. I was just wondering if you can fork a process in .NET like you would[/color]
in C.[color=blue]
> Thanks
> Jenna[/color]
Comment
-
Re: Forking processes in .NET
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...inquir ing minds want to know.
Tom Dacon
Dacon Software Consulting
"Miha Markic [MVP C#]" <miha at rthand com> wrote in message
news:%23sZ9VdlT EHA.2580@TK2MSF TNGP12.phx.gbl. ..[color=blue]
> 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
>
> "JennaS" <anonymous@disc ussions.microso ft.com> wrote in message
> news:95F9EE1B-6C61-4741-9584-3097194AC8F2@mi crosoft.com...[color=green]
> > Hi. I was just wondering if you can fork a process in .NET like you[/color][/color]
would[color=blue]
> in C.[color=green]
> > Thanks
> > Jenna[/color]
>
>[/color]
Comment
-
Re: Forking processes in .NET
"Tom Dacon" <Tom-@t-dacons.com> wrote in message
news:%23NyUe2pT EHA.384@TK2MSFT NGP10.phx.gbl.. .[color=blue]
> 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,[/color]
and[color=blue]
> 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[/color]
easy.[color=blue]
> Is there anyone besides me that thinks that the fork business in Unix,[/color]
both[color=blue]
> from the conceptual viewpoint and the implementation viewpoint, is truly
> bizarre?
>
> Just asking...inquir ing minds want to know.
>[/color]
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???".
Comment
-
Re: Forking processes in .NET
> You're not the only one that thinks that fork is forked! Every time I see[color=blue]
> this question I think "Why would you want it???".[/color]
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
Comment
-
Re: Forking processes in .NET
Hi guys,
"Tom Dacon" <Tom-@t-dacons.com> wrote in message
news:%23ZbeM3aU EHA.2908@TK2MSF TNGP10.phx.gbl. ..[color=blue][color=green]
> > You're not the only one that thinks that fork is forked! Every time I[/color][/color]
see[color=blue][color=green]
> > this question I think "Why would you want it???".[/color]
>
> 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).[/color]
I prefer threads approach - it seems more clean and isolated to me.
--
Miha Markic [MVP C#] - RightHand .NET consulting & development
miha at rthand com
Comment
-
Re: Forking processes in .NET
"Tom Dacon" <Tom-@t-dacons.com> wrote in message
news:%23ZbeM3aU EHA.2908@TK2MSF TNGP10.phx.gbl. ..[color=blue][color=green]
> > You're not the only one that thinks that fork is forked! Every time I[/color][/color]
see[color=blue][color=green]
> > this question I think "Why would you want it???".[/color]
>
> 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).
>[/color]
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[i] = b[i] + c[i];
}
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[i] = b[i] + c[i];
}
waitpid(child);
}
else if ( childpid == 0 ) {
for( int i = 500; i < 1000; ++i )
{
a[i] = b[i] + c[i];
}
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
[color=blue]
> 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[/color]
of[color=blue]
> 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[/color]
is[color=blue]
> 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[/color]
mine,[color=blue]
> // so I guess I'll go off and process the requests for this[/color]
session...[color=blue]
> }
> 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[/color]
bipolar[color=blue]
> 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[/color]
this[color=blue]
> 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
>
>
>
>
>
>
>[/color]
Comment
-
Re: Forking processes in .NET
[color=blue]
> 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:[/color]
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
Comment
-
Re: Forking processes in .NET
> 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
Comment
Comment