Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#852 closed task (complete)

boost::msgq as possible replacement of MSGQ

Reported by: vorner Owned by: UnAssigned
Priority: medium Milestone: Sprint-20110419
Component: Unclassified Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity:
Sub-Project: Feature Depending on Ticket:
Estimated Difficulty: 1.0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

This is subtask of #765, investigating if boost::msgq could be used as a replacement for our MSGQ.

Subtickets

Change History (4)

comment:1 Changed 9 years ago by vorner

  • Owner changed from vorner to UnAssigned
  • Status changed from new to reviewing

Hello

I can't find anything else than just boost::interprocess::message_queue. boost::msgq seems not to exist.

And the message_queue seems to be something different than what we need. It allows creation of a message queue that is shared between processes (it is in shared memory, so it has the same problem with staying there for ever if not deleted, etc.). Then a message can be put into it and taken out (with blocking/non-blocking/timeouting mode). Anybody is allowed to put in and to take out. The first message just falls out (it has priority, but no addressing).

So, if we wanted to use it, we could rewrite our msgq using this, there could be a message queue for messages going into the router (msgq) and then one message queue for each connected process where msgq would put the messages for it. It could solve some of our problems (read and write of single message is atomic, we are told when the queue is full, etc.), but it would bring new ones (we need to make sure we remove the shared memory, if a process crashes, msgq wouldn't get a closed file descriptor, we would need to handle naming somehow ourself, the length of single message is limited (we set the limit at construction, but the maximum size is set in stone since then)). And we would need to write python bindings.

The interprocess library is header only, but might need some date-time library that is built. It uses the mutexes which gave us some trouble.

Some people on the forums seem to note stuff about rough edges and slight immaturity, but that might be older.

So, if everything else fails, we probably should look into if we want to replace our sockets with this, but it's not a complete solution.

Or, did I look at something else? Did anybody know of anything that could be noted as boost::msgq?

Thanks

comment:2 Changed 9 years ago by vorner

  • Milestone set to Sprint-20110419

comment:3 Changed 9 years ago by shane

  • Resolution set to complete
  • Status changed from reviewing to closed

I think that this summary is accurate: boost::multiprocess::message_queue does not really buy us much.

However... I looked through the Boost libraries and it looks like boost::mpi may be closer to what we want. I'll make a separate ticket for that!

comment:4 Changed 9 years ago by vorner

  • Estimated Difficulty changed from 0.0 to 1
Note: See TracTickets for help on using tickets.