Re: Problem with Cygwin's fdopen and Windows handles

[Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>]

On Mon, May 30, 2011 at 07:34:27AM +0000, Juanjo wrote:
>Christopher Faylor writes:
>>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.
>
>If this was true, the function should have then been removed from the
>manual or marked as not working.  But I believe this is not right, for
>read() and file handlers work perfectly and the problem only arises
>with fread() !!!

Please calm down.

I guess I shouldn't have said the "doesn't really work" and stuck with
"of limited utility".  fds attached with cygwin_attach_handle_to_fd are
not fully functional.

>> 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.
>
>Sorry, no time nor interest to do it myself.

I wasn't asking you to do it.  I don't think anyone cares enough about
the problem to add the low-level Windows code required to augment
cygwin_attach_handle_to_fd.

>>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.
>
>I have seen messages in a sibling mailing list reporting that fork()
>fails when a program injects libraries using various mechanisms
>http://sourceware.org/ml/cygwin/2011-04/msg00185.html

"sibling mailing list"?  That is this mailing list.

>In our case we just have one core library and other libraries that are
>compiled on the fly and which are loaded with dlopen().  Loading is
>fine and there are no collisions, the problem is that when fork()
>reloads them they do not end up in the right positions and cygwin
>complains.  It is not our job to hardcode addresses for libraries to be
>loaded and do what cygwin is not doing right, which is to determine the
>right order of loading.

There has been lots and lots of mailing list discussion about how hard
it is to get dll load order correct in Windows when Cygwin emulates
fork.

If you have an application which uses a lot of dlls then best practice
for Windows DLLs is to build them with unique load addresses.  Barring
that you could rebase them with cygwin's rebase or rebaseall utilties.
Setting unique base addresses will actually cause your application to
load slightly faster whether you use Cygwin or not.
--
Christopher Faylor			spammer? ->	aaaspam@sourceware.org
Cygwin Co-Project Leader

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple