I will work on purging cygwin of fork calls, and hopefully
that will fix the problem. We need to do this anyway for
a mingw distribution. Bonus: hopefully performance will
improve when calling system functions.
Anybody have experience using pipes in the Windows API?
Hints are much appreciated. I think we can get away with
half-duplex pipes almost everywhere.
> I've finally got a few lines of code which reproduce the error
> message I see in cygwin for each dynamically loaded oct-file
> every time I call a system function.
Paul, Cygwin fork does a lot of magic, and using dl* family instead of
LoadLibrary/GetProcAddress takes care of some of that. 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've been out of touch with Cygwin for
too long to know if things have changed in this area or not.
>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
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?
I've found talk about using threads, but I don't think we are anywhere
for threads in Octave.