Re: cygwin fork bug on Windows 9x

[Paul Kienzle]

Mumit Khan wrote:

> Paul, Cygwin fork does a lot of magic, and using dl* family instead of
> LoadLibrary/GetProcAddress takes care of some of that. 
Paraphrasing Octave's code path through cygwin's dlopen, dlsym:

   SetResourceLock
   get_full_path_of_dll
   LoadLibrary
   ReleaseResourceLock
   GetProcAddress

So no magic on the dl end.

> There are issues
> of remapping the loaded DLLs in the child, and that's just one of very
> many things that fork has to do.
I haven't looked at the code from fork. 

I propose that instead of using a unix interface to the OS, we use an 
interface that is
appropriate,  and let the OS dependent bits sort it out.  E.g., rather 
than pipe-fork-exec
in procstream, use the popen call which is available in MSVCRT.  
Similarly, define an
interface to an async version of system which unix implements as 
fork-exec and windows
implements as spawn, or maybe even CreateProcess.  Almost all calls to 
fork can be
avoided using a higher level interface which can be implemented in a 
system dependent way.

BTW, anyone know how to do sockets on windows without invoking fork?  
The pages
I've found talk about using threads, but I don't think we are anywhere 
near ready
for threads in Octave.

Paul Kienzle
address@hidden