Mail Archives: cygwin-developers/1998/12/31/10:30:58
Christopher Faylor <cgf AT cygnus DOT com> writes:
>
> I don't believe that signal handling should be a problem. I don't think
> that the signal thread can't be initialized in the DLL initialization
> code though. It relies on other things in the DLL having been initialized
> previously.
After the code breakage in B20 thanks to my hack to DLL initialization,
we had an email exchange about signal thread initialization. Basically,
I ended up leaving signal thread initialization alone since it was hanging
Cygwin DLL when being loaded from non-Cygwin apps. That's the reason I ask.
>
> For signals to work, then the process has to have a cygwin pid. To
> have a cygwin pid means that the cygwin shared memory has to be aquired
> and properly initialized.
>
> All of these rely on a working malloc. It doesn't have to be the malloc
> in cygwin necessarily, and, in fact, it probably shouldn't be the cygwin
> malloc. That means that the hooks that are already in cygwin for using
> a different malloc will have to be exploited. That will be tricky.
We should be able to use the Cygwin malloc, as long as the Cygwin code
doesn't let malloc/free cross DLL boundaries. I've done it quite
successfully with a reasonably large Java JNI (I've tried up to 20M
dynamic allocation for a 3D Partial Differential solver).
> Hmm. I just scanned through dll_crt0_1. That seems to be about it.
> So, except for fork, most of the cygwin functionality should be
> possible.
We just tell people that they can't use fork. Just like they can't use
true shared libraries, /proc fs, convertibles in Wisconsin winters, ...
I believe our focus should be on writing extension modules for various
applications out there (Java, Matlab, and so on) that are not available
as Cygwin apps; if we can support those well, and I haven't requests
for anything else so far, we should be almost there.
Regards,
Mumit
- Raw text -