mq on kqueue broken after upgrade to FreeBSD 11

[Lewis Donzis]

> On Oct 5, 2016, at 8:14 AM, Konstantin Belousov <kostikbel at gmail.com> wrote:
> 
> On Mon, Oct 03, 2016 at 07:27:54AM -0500, Lewis Donzis wrote:
>> That's a very good point, I hadn't considered those other functions,
>> and it???s clear that an fd is allocated and stored in the mqd_t.
>> But using close() instead of mq_close() wouldn't delete the sigevent
>> or free the memory that was allocated by mq_open(). In other words,
>> I don't understand why you'd ever want/need to use close() on the
>> underlying fd.
> 
> I really have troubles giving any useful interpretation to your question.
> OS provides the kernel service which backs the posix message queue
> implementation in userspace, as a file descriptor.  To release resources
> designated by the file descriptor, it must be closed, as in, close(2)
> must be called.  Librt does this in mq_close(3).
> 
> Why should I need to show a case of using close(2) on kernel mq
> descriptor (perhaps besides librt) ? And how this changes or augments
> the fact that kmq is file descriptor ?

Sorry, perhaps I wasn’t clear.  As I read it, you suggested that you "can and should call close()" on the fd in an mqd_t, and my point was simply that such practice would obviously be bad because it would fail to release resources allocated by mq_open().  So yes, the correct way to close an mqueue is via mq_close(), i.e., we’re not meant to circumvent the librt functions.

The problem is that it’s not exactly clean that we have mq_*() functions for some operations, whereas for others, we’re required to convert the mqd_t to an fd.  Of course, this is no fault of FreeBSD, and perhaps the POSIX folks should have come up with a better way to address this.  For example, they could have specified a portable way to get the underlying fd from an mqd_t and specified what can and cannot be done with the fd.

lew