cygwin fork bug on Windows 9x

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

cygwin fork bug on Windows 9x

Paul Kienzle
Hi,

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.


The following code demonstrates the error:

--- dynmain.cc:
#include <iostream>
#include <windows.h>
int main(int argc, char *argv[])
{
HINSTANCE handle = LoadLibrary("dynsub.dll");
std::cout << "# Calling fork\n";
std::cout << (fork()?"parent\n":"child\n");
return 0;
}

--- dynsub.c:
#include <stdio.h>
void dynsub(void) { printf("in dynsub\n"); }

--- Makefile:
all: dynsub.dll dynmain.exe
dynmain.exe: dynmain.cc  ; g++ -o $@ $<
dynsub.dll : dynsub.c   ; gcc -shared -o $@ $<


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.

Thanks in advance,

Paul Kienzle
[hidden email]



Reply | Threaded
Open this post in threaded view
|

Re: cygwin fork bug on Windows 9x

Mumit Khan-4
On Sun, 2 Feb 2003, Paul Kienzle wrote:

> 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.

Mumit




Reply | Threaded
Open this post in threaded view
|

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
[hidden email]



Reply | Threaded
Open this post in threaded view
|

Re: cygwin fork bug on Windows 9x

David Bateman-3
> I've found talk about using threads, but I don't think we are anywhere
> near ready for threads in Octave.

Yuk, I can't run Matlab under Mosix because of the threads, now I won't
be able to run Octave either :-)

D.

--
David Bateman                                [hidden email]
Motorola CRM                                 +33 1 69 35 25 00 (Ph)
Espace Technologique, Commune de St Aubin    +33 1 69 35 25 01 (Fax)
91193 Gif-Sur-Yvette FRANCE

The information contained in this communication has been classified as:

[x] General Business Information
[ ] Motorola Internal Use Only
[ ] Motorola Confidential Proprietary