BP> Lets step back and think about this for a moment. I see why you would
BP> want to use socketpair for the application that was mentioned. But, is
BP> this really something to add to SDL_net? Or, should we be thinking about
BP> an new library, SDL_process, that provides the functionality of fork,
BP> exec, popen, and interprocess communication? I think we could come up
BP> with a small set of APIs that are both portable and cover the need to
BP> create processes and communicate with them. I guess what I’m saying is
BP> that there isn’t much point in having a portable version of socketpair
BP> if there isn’t a portable fork or popen or what not.
That makes sense. I was thinking about SDL_net because of sockets, but
you have a point there. Perhaps a better name would be SDL_system? But
either way, the name isn’t important - the idea is.
I’ll certainly write a socketpair() replacement very quickly, I’ll get
it done at the weekend as a bit of a break from GBA programming. But
the rest of it would still need to be written. Would you be interested
in helping?
BP> Personally, I would prefer an API like popen that gives me a
BP> bidirectional connection to the new process. I know how to do that with
BP> standard Unix APIs, but it would be so nice to have one simple API to do
BP> the job.
Yes, you’re right. I’ve been using popen() when writing a server at
work and found pthreads quite nice. I never needed bidirectional
connections because of the modular design, but I can definitely see
where it would be useful!
Neil Griffiths <n.griffiths at virgin.net> escribi?:
I’ll certainly write a socketpair() replacement very quickly, I’ll get
it done at the weekend as a bit of a break from GBA programming. But
the rest of it would still need to be written. Would you be interested
in helping?
Could you please note fork() is not the same as creating threads?
BP> Lets step back and think about this for a moment. I see why you would
BP> want to use socketpair for the application that was mentioned. But, is
BP> this really something to add to SDL_net? Or, should we be thinking about
BP> an new library, SDL_process, that provides the functionality of fork,
BP> exec, popen, and interprocess communication? I think we could come up
BP> with a small set of APIs that are both portable and cover the need to
BP> create processes and communicate with them. I guess what I’m saying is
BP> that there isn’t much point in having a portable version of socketpair
BP> if there isn’t a portable fork or popen or what not.
That makes sense. I was thinking about SDL_net because of sockets, but
you have a point there. Perhaps a better name would be SDL_system? But
either way, the name isn’t important - the idea is.
I’ll certainly write a socketpair() replacement very quickly, I’ll get
it done at the weekend as a bit of a break from GBA programming. But
the rest of it would still need to be written. Would you be interested
in helping?
I can help on the UNIX/Linux side, but its been 6 years since I wrote
any native Windows code. All the code I’ve written on Windows in that
time was in Java. And, Java ain’t Windows.
BP> Personally, I would prefer an API like popen that gives me a
BP> bidirectional connection to the new process. I know how to do that with
BP> standard Unix APIs, but it would be so nice to have one simple API to do
BP> the job.
Yes, you’re right. I’ve been using popen() when writing a server at
work and found pthreads quite nice. I never needed bidirectional
connections because of the modular design, but I can definitely see
where it would be useful!
I posted code on USENET in 1988 called ile.c that forks and execs
another program and communicates with it over pty/tty pairs. That code
should give us a good idea how to do a popen with with bidirectional
communication. I can post the code, send it to you, or you can find a
shell archive at http://open-systems.ufl.edu/mirrors/ftp.isc.org/usenet/comp.sources.unix/volume25/ile
Use listen(), then accept() on both main.recv and thread.recv and use
connect() to 127.0.0.1 on main.send and thread.send.
So, the most obvious solution, and the one i was trying to avoid.
Ok, understood.
This is the reason socketpair has sense only under Unix platforms. Windows
doesn’t support fork.
I mean, using Windows you can spawn a child process, but there’s no way for
the child process to inherit nor use the file descriptors from its parent.
Even pipe() is useless?
I’ll have a try with mingw…
Again, if you’re concerned about speed (and admitely the Windows TCP stack
isn’t by any means optimized for speed) you might consider the use of
shared memory. There are several multiplatform libraries for managing
shared memory out there.
Mmmh… is not my case.
I think w32 users will have to launch client and dedicated server separately,
at least for now.
JLS> Could you please note fork() is not the same as creating threads?
You don’t say?
I’m not entirely sure how to go about doing a fork() in Win32 - but I
suspect it could be done with the clever use of function pointers. I
would imagine that at least somebody has gotten fork() working on
Win32 before - like the people who wrote the Perl interpreter for
Win32. I haven’t tried, but I would imagine they’d need to get fork()
working.
If nothing else, I imagine doing it by using a bit of assembly. You’d
have to use stdcall then, but then at least you could “pop eax” and
you’d have the address of the location where you’d be using fork().
Creating a thread based on that address then. And remembering to push
it back on before returning.
BP> I can help on the UNIX/Linux side, but its been 6 years since I wrote
BP> any native Windows code. All the code I’ve written on Windows in that
BP> time was in Java. And, Java ain’t Windows.
Well, I’ll be looking into how to fork() on Win32 at the weekend then. I was
hoping you’d say you’d do that.
BP> I posted code on USENET in 1988 called ile.c that forks and execs
BP> another program and communicates with it over pty/tty pairs. That code
BP> should give us a good idea how to do a popen with with bidirectional
BP> communication. I can post the code, send it to you, or you can find a
BP> shell archive at
BP> http://open-systems.ufl.edu/mirrors/ftp.isc.org/usenet/comp.sources.unix/volume25/ile
I haven’t got time right now to take a look, but I agree that it
sounds like a good idea of how to do it. I’ll take a look later on and
I’ll write back!
BP> I can help on the UNIX/Linux side, but its been 6 years since I wrote
BP> any native Windows code. All the code I’ve written on Windows in that
BP> time was in Java. And, Java ain’t Windows.
Well, I’ll be looking into how to fork() on Win32 at the weekend then. I
was
hoping you’d say you’d do that.
Windows doesn’t have any support for duplicating processes like fork() does.
The way to create processes is to use exec* family of functions, or the
Win32
API WinExec()/CreateProcess() calls.
Windows favours threads over processes. In Windows processes are just a way
to
group threads.
If you want use fork() to handle multiple tasks you are better off by using
threads.
–
Paulo Pinto
----- Original Message -----
From: n.griffiths@virgin.net (Neil Griffiths)
To: “Bob Pendleton”
Sent: Friday, September 06, 2002 9:07 AM
Subject: Re[2]: [SDL] SDL_net and socketpair
I
would imagine that at least somebody has gotten fork() working on
Win32 before
Cygwin certainly is able to fork() processes, and I believe AT&T’s UWin
can, too. Probably Microsoft’s Interix (now called Unix Services or
some such silliness) can, too.
like the people who wrote the Perl interpreter for
Win32.
I wouldn’t be surprised if the Perl implementation does something
entirely different, being an interpreted language. If I were you, I’d
look at the Cygwin implementation because that manages to fool all
programs, not just Perl ones.
I can socketpair(), fork() and then send() and recv() data back and forth
between parent and child.
This is the reason socketpair has sense only under Unix platforms. Windows
doesn’t support fork.
True, if you ignore the way fork() has been faked on Windows. (See my
earlier post.)
However, Windows does support passing file/socket handles under limited
circumstances. See my FAQ, link below. In particular, the “Passing
Sockets Between Processes” article and the Unix compatibility article on
the equivalence of file and socket handles.
Again, if you’re concerned about speed (and admitely the Windows TCP stack
isn’t by any means optimized for speed)
The Win9x stacks are quite weak, yes, but the NT-derived stacks manage
to get many things right. In some cases, they’re better than Linux.
(And in others, worse.) Nothing successful sucks absolutely.–
= Winsock Programmer’s FAQ: http://tangentsoft.net/wskfaq/
JakobAm Freitag, 6. September 2002 17:03 schrieb Warren Young:
The Win9x stacks are quite weak, yes, but the NT-derived stacks manage
to get many things right. In some cases, they’re better than Linux.
(And in others, worse.) Nothing successful sucks absolutely.
– http://www.obilot.de | Windows is a 32 bit shell for a 16 bit extension to an
8 bit Operating System designed for a 4 bit microchip by a 2 bit company
which can’t stand one bit of competition.
