X-Recipient: archive-cygwin@delorie.com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:subject:date:message-id:references
	:in-reply-to:content-type:content-transfer-encoding
	:mime-version; q=dns; s=default; b=pfWx5etA82uQDzUMD+OKh8hkmOXf/
	/O6Ez2tbtpUdBldqCcixbv6+3S4dqbBDCxZSgbFmJACG1WIvVM7ldHPrN7YFioyz
	7rMZNNnjqlU/h6iN2vxjTj10Cp8zn7ivxhPCr65Xr8FX5vErkOVQWor/bK5OJR4d
	g/XfcoTt+IuZbA=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:subject:date:message-id:references
	:in-reply-to:content-type:content-transfer-encoding
	:mime-version; s=default; bh=DA+ZxoW48yPPJb7PFg+cP69/gnc=; b=pvg
	DVJjxO/EG7qVRduuHhBfTNMPukCFqLsFIDX2+u2wfLvoyOszK9y1JzIBuGQmgem7
	tEm83+LmvpK9lkEjcTCwqczAQI3psK9sZNx73csjnKP/p4R/XzgNWMSd+Eoe08U5
	VTk2s9W6DroMZ31SQWnJxh96S5cPIi362XJezJa4=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe@cygwin.com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin@cygwin.com>
List-Help: <mailto:cygwin-help@cygwin.com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Delivered-To: mailing list cygwin@cygwin.com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=3.4 required=5.0 tests=AWL,BAYES_00,CYGWIN_OWNER_BODY,MIME_BASE64_BLANKS,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=no version=3.3.2
X-HELO: mail-out.astrium.eads.net
From: "KEREP, Mladen" <mladen.kerep@airbus.com>
To: "cygwin@cygwin.com" <cygwin@cygwin.com>
Subject: RE: Handles returned by mq_open are not valid file descriptors as supposed to be under native linux distributions
Date: Mon, 30 Mar 2015 14:38:28 +0000
Message-ID: <556891A1F0F6154CB3DD7811A49431534D3B8406@FOWEXMC003.de.astrium.corp>
References: <556891A1F0F6154CB3DD7811A49431534D3B8027@FOWEXMC003.de.astrium.corp> <6744_1427719032_55194377_6744_15232_1_20150330123643.GC10785@calimero.vinschen.de>
In-Reply-To: <6744_1427719032_55194377_6744_15232_1_20150330123643.GC10785@calimero.vinschen.de>
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
X-TM-AS-GCONF: 00
X-IsSubscribed: yes
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by delorie.com id t2UEcliF005076

>For a start, since what you're doing sounds pretty commercial to me,
>may I point out https://cygwin.com/licensing.html?  May I assume your
>code is open source?

We're doing researches, principally under native linux. Different target platforms
are evaluated. That's why we're trying Cygwin as well, but so far, due to the described
inconsistencies, were not able to generate any useful outputs. It would be great, 
if mqd_t will be a file descriptor one day.

Thanks for your fast response.


>-----Original Message-----
>From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com] On Behalf Of
>Corinna Vinschen
>Sent: Monday, March 30, 2015 2:37 PM
>To: cygwin@cygwin.com
>Subject: Re: Handles returned by mq_open are not valid file descriptors as
>supposed to be under native linux distributions
>
>On Mar 27 09:30, KEREP, Mladen wrote:
>> We're using POSIX message queues to pass messages between processes.
>> For this we've build a library layer to be able to use message queues
>> on different platforms. Basically linux (debian, Ubuntu, archlinux,
>> rasbian) is the development platform, but also vxworks platforms are
>> supported.
>>
>> Several message queues are opened through mq_open calls and the
>> returned handles are organized in file descriptor sets (fd_set). The
>> set is then passed over to a select(2) call, which blocks processing
>> and returns as soon as any message in any of the queues arrives.
>>
>> This works under linux, since the handles returned are valid file
>> descriptors and the macros FD_ZERO / FD_SET are able to handle that
>> handles.
>>
>> However, under Cygwin,
>
>For a start, since what you're doing sounds pretty commercial to me,
>may I point out https://cygwin.com/licensing.html?  May I assume your
>code is open source?
>
>> mq_open does not directly return file handles,
>> but pointers to (unknown) data structures in memory (ref.
>> http://sourceware.org/ml/cygwin/2013-07/msg00179.html), which cannot
>> be used with FD_ZERO, FD_SET, so not with select(2). I know from the
>> man pages (mq_open): "Polling message queue descriptors On Linux, a
>> message queue descriptor is actually a file descriptor, and can be
>> monitored using select(2), poll(2), or epoll(7).  This is not
>> portable."
>>
>> mq_open() and select() conform to POSIX.1-2001, at least under linux,
>> but also under Cygwin ?  How can this be modified, so that it works
>> under Cygwin as well ?
>
>"This is not portable" is the important hint in the Linux man page.  On
>Cygwin we're using basically the implementation from W. Richard Stevens,
>as published for his book "UNIX Network Programming, Volume 2,
>Interprocess communication".  It doesn't support the Linux extensions
>but, yes, it's POSIX compliant, see POSIX.1-2008:
>
> "A message queue descriptor *may* be implemented using a file descriptor,
>  in which case applications can open up to at least {OPEN_MAX} file and
>  message queues." [emphasis mine]
>
>Note that mq_open doesn't return an int, but a special message queue type
>mqd_t for a reason.  Again, if you use message queues with select, you're
>creating non-portable code.
>
>Having said that, it *would* be possible to change the implementation to
>make mqd_t a file descriptor and to support the Linux extension, but I'm
>not planning to do so for the time being.
>
>But, as always, patches are welcome.
>
>
>Corinna
>
>--
>Corinna Vinschen                  Please, send mails regarding Cygwin to
>Cygwin Maintainer                 cygwin AT cygwin DOT com
>Red Hat
>
>This mail has originated outside your organization, either from an external
>partner or the Global Internet.
>Keep this in mind if you answer this message.
>


