Mail Archives: cygwin-developers/1998/12/31/10:38:32
On Thu, Dec 31, 1998 at 12:00:29PM -0600, Mumit Khan wrote:
>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.
Yes, I remember. I think that signals could conceivably be one of the things
that would be useful, though. So, I think we should pursue getting them
working.
>> 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).
I'd be concerned about heap fragmentation and general confusion if there
are two different mallocs in use.
>> 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, ...
Yes.
>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.
Perl is another goal. We might be able to have the standard Windows
perl load the cygwin dll so that it can use cygwin path specs.
-chris
- Raw text -