Handles returned by mq_open are not valid file descriptors as supposed to be under native linux distributions

[KEREP, Mladen]

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