This is the mail archive of the
mailing list for the Cygwin project.
Re: Problem with Cygwin's fdopen and Windows handles
- From: Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Sun, 29 May 2011 19:38:42 -0400
- Subject: Re: Problem with Cygwin's fdopen and Windows handles
- References: <loom.20110529T133128email@example.com>
- Reply-to: cygwin at cygwin dot com
On Sun, May 29, 2011 at 11:35:03AM +0000, Juanjo wrote:
>Actually there are two different problems related to my implementation of a
>Common Lisp environment, ecl (http://ecls.sf.net)
>The first one has to do with fork() not working, due to the fact that ECL
>injects DLLs using dlopen() and they are then improperly loaded. I have seen in
>the mailing list that this is a known problem with no solution so far.
>To cope with that problem I had to resort to CreateProcess, a Windows routine
>that allows us to redirect the input/output/error channels of a process as
>needed. The problem I have is that the C streams that result from the Windows
>handle can only be read with read() and not with fread(). This is a problem
>because the ECL environment needs buffered I/O, with locking and so on, and we
>rely on C streams for that.
>I attach a small test program that segfaults when using fread() on the stream
>created with fdopen(). notice that read() works.
>Any help is really welcome and appreciated.
Unfortunately, cygwin_attach_handle_to_fd doesn't really work. Cygwin
needs to know the type of handle it is attaching in order to set up
the correct type of file handler. Since it doesn't do that the handle
is of limited utility.
It is possible for the function to be more intelligent since other parts
of cygwin try to figure out the handle type by querying attributes of the
handle. So this is a http://cygwin.com/acronyms#SHTDI scenario.
I don't know what you mean by dlopen() causing fork not to work. That's
obviously not normally the case. If you are seeing something like this
then maybe your dlls are not properly based to avoid collisions. If
that is the case then you should change your link line to specify unique
load addresses for each dll.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple