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


Christopher Faylor <cgf-use-the-mailinglist-please <at> cygwin.com> 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 http://cygwin.com/acronyms#SHTDI 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
     http://sourceware.org/ml/cygwin/2011-04/msg00185.html

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.

Juanjo


--
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


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