This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problem with Cygwin's fdopen and Windows handles

On 30/05/2011 3:34 AM, Juanjo wrote:
Christopher Faylor<cgf-use-the-mailinglist-please<at>> 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() !!!

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 scenario.
Sorry, no time nor interest to do it myself. I am just reporting it here
because some users of our software experienced this problem. I have a
lot of SHTDI in my own project and in any case, as I said before, I believe
this is not the cause of the problem -- it lays in fread()/fdopen()
not in read().

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
That is a *statically linked* test program whose dependent libraries have intentional dll base collisions. Be glad you're using dlopen -- at least there cygwin can usually bully Windows into doing what it wants.

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.
Unfortunately, the Windows loader has a bad habit of shuffling things around the address space, and it does its damage before the cygwin dll even loads. Cygwin does its best to hide all this from you, but Windows Vista/7 actually makes it impossible to guarantee every fork will succeed. It's all part of the cost of doing business with Windows.

That said, rebasing and setting tsaware on your dlls helps a lot, and there are patches in the works which should further improve the odds for precisely your scenario.


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]