Mail Archives: cygwin/2011/05/30/07:07:18
On 30/05/2011 3:34 AM, Juanjo wrote:
> 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
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.
Ryan
--
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
- Raw text -