Add `System.Posix.MessageQueue`. about unix

[chessai]

Sorry that it's too late, but https://github.com/andrewthad/posix-api has great support for posix message queues.

…

On Sun, Nov 24, 2019, 4:34 AM Magnus Therning ***@***.***> wrote: Closed #47 <#47>. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#47?email_source=notifications&email_token=AEOIX244YOBB2IPQ3JLAZ7TQVJDDTA5CNFSM4BQW4SW2YY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGOVBXRGUY#event-2825851731>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEOIX26NTU7D7SJ5T6IDNX3QVJDDTANCNFSM4BQW4SWQ> .

[argiopetech]

Both sys/msg.h and mqueue.h are on the list of "Not Supported" "Unsupported interfaces" headers in Posix.hs. This is in contrast to several headers in the "To be supported" category, so it would appear that message wueurs are blocked for some reason other than lack of volunteers to write an interface. I'm not sure of the rationale for this, but I can look into it.

For the record, can you share a use case that might encourage adoption by the Core Libraries Committee of a patch adding message queues?

[magthe]

It's a standard IPC method that differ from (named) pipes:

• They have internal structure (pipes are just about pumping bits)
• They are priority driven and the queue stays ordered so the oldest message with the highest priority is at the front.
• The programmer has control over various aspects of the queue, on creation one can set
  • size of queue (number of messages)
  • max size of message
• It's possible to determine that state of a queue

The use case is of course to allow writing programs in Haskell that communicate via message queues.

[argiopetech]

Good enough for me. I'll put some feelers out on the mailing list to see I can determine why (or if) this was slated not to be implemented.

In the event that there is no compelling reason for us not to merge a patch adding this functionality, would you be willing to submit such a patch?

[magthe]

Sure, I'd be willing to make an attempt at adding it.

[argiopetech]

Thanks! I am, of course, willing to help verify/integrate, but I'm in the middle of a move and remodel at the moment and can't take the lead.

I've thrown a request for info on the libraries mailing list. Pending a response there, I see no reason not to integrate anything created. Worst case, it could be spun into a new library.

On that note, posix-realtme provides a set of basic wrappers around mqueue.h (realtime message queues), which may help with creating a wrapper around sys/queue.h or even solve your challenge outright.

[magthe]

mqueue.h is Posix message queues: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/mqueue.h.html

[argiopetech]

mqueue.h is REALTIME (caps and bold per the spec) message queues. One Haskell binding (recently supported, albeit of "provisional" stability) to that header is provided in posix-realtime.

What I think of as "POSIX Message Queues" is provided by sys/msg.h. There is not currently a Haskell binding to those headers of which I am aware.

Which are you looking for? If the former, a solution exists. If the latter, a solution will need to be built. I'll keep this issue open in either case, as I'm legitimately curious why the unix library has (potentially) chosen not to support either.

[magthe]

sys/msg.h is commonly called System V message queues (or XSI message queues).

The message queues I'm interested are the ones specified in mqueue.h.

[argiopetech]

Fair enough. Good luck with the bindings in posix-realtime.

Pending the mailing list, I may get in touch with Michal Gajda and see if he would like to have posix-realtime integrated into unix.

[magthe]

Yes, is there any point in keeping them separate?

(A quick glance shows that the mqueue support in posix-realtime aren't complete :( )

[argiopetech]

Incompleteness would, of course, be a valid reason not to merge posix-realtime into unix. Other than that, or an objection by the author of posix-realtime, I have no personal knowledge of a reason not to merge them; however, there may be a historical reason of which I'm not aware. The "Unsupported interfaces" list was created in 2002 and hasn't seen much modification, while I've only been maintaining unix since earlier this year.

My gut feeling is that the path of least resistance would be to add the missing functionality in posix-realtime's System.Posix.Realtime.MQueue, add that file (and any appropriate tests) to unix, and submit it as a pull request here on Github to both unix and posix-realtime. Worst case scenario, you have a usable local copy. Best case scenario it is accepted into posix-realtime and into unix (again, pending that historical data from the mailing list) and benefits everyone.

[magthe]

My need for this has disappeared so I'm closing this.