DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	 q=dns; s=default; b=QK+eVg7qLivx2MuqzFDyngNTqxe7ATb7znI6+fbETAk
	7eRgr9h/tPwNeC17kYI3w4iEcmAMtCJBR4igZsqgKpiplfKTH0uTjqRjBx4SDYDr
	pMfdIXMKenTg+N5pNqIyTIvkxuFLNZjVy07gpiHATJ+qQoRCThxBb2bXWgYAUpzY
	=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Message-ID: <53B20373.4010100@etr-usa.com>
Date: Mon, 30 Jun 2014 18:40:19 -0600
From: Warren Young <warren@etr-usa.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: cygwin@cygwin.com
Subject: Re: can't share fifo between 32-bit and 64-bit Cygwins
References: <0D835E9B9CD07F40A48423F80D3B5A702E7D8967@USA7109MB022.na.xerox.net> <53B1C3B8.9080401@gmail.com> <20140630231824.GA7883@ednor.casa.cgf.cx>
In-Reply-To: <20140630231824.GA7883@ednor.casa.cgf.cx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 6/30/2014 17:18, Christopher Faylor wrote:
> On Mon, Jun 30, 2014 at 10:08:24PM +0200, Marco Atzeri wrote:
>> On 30/06/2014 20:04, Nellis, Kenneth wrote:
>>>
>>> If I create a named pipe (mkfifo), as long as I write to and read from using
>>> either 32-bit Cygwin or 64-bit Cygwin, all works fine, but if I write with either
>>> one and read with the other, both processes hang.
>>
>> why do you expect such things to work ?
>> You have two separate simulation layers independent from each other.
>> Nothing is in place to pass the data from the 32 bit layer to the 64 layer.
>
> Right.  Fifos, signals, ptys - all of them are distinct entities that won't
> work between 32 bit and 64 bit or even between different Cygwin installations
> on the same system.

In principle, one could build a 32-bit cygwin1.dll that would depend on 
the existence of a 64-bit cygwin1.dll, doing nothing other than acting 
as a thunking layer.  Every 32-bit Cygwin app that makes a call on that 
DLL would actually be talking to the 64-bit DLL, which would do all the 
work.

Microsoft has done such trickery several times to my knowledge, but MS 
has lots of financial incentive to do go to the effort it takes to build 
such things.  It's not trivial.

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