X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=0.2 required=5.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED,RCVD_NUMERIC_HELO,SPF_HELO_PASS,TW_CG,T_RP_MATCHES_RCVD,T_TO_NO_BRKTS_FREEMAIL
X-Spam-Check-By:	sourceware.org
To:	cygwin AT cygwin DOT com
From:	Juanjo <juanjose DOT garciaripoll AT gmail DOT com>
Subject:	Re: Problem with Cygwin's fdopen and Windows handles
Date:	Mon, 30 May 2011 07:34:27 +0000 (UTC)
Lines:	41
Message-ID:	<loom.20110530T093057-556@post.gmane.org>
References:	<loom DOT 20110529T133128-564 AT post DOT gmane DOT org> <20110529233841 DOT GC5283 AT ednor DOT casa DOT cgf DOT cx>
Mime-Version:	1.0
User-Agent:	Loom/3.14 (http://gmane.org/)
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

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

- Raw text -