On Wed, Jun 18, 2014 at 4:56 PM, Ion Gaztañaga wrote:

El 18/06/2014 17:03, Joseph Van Riper escribió:

...

It's strange that I closed it without any comment. I can't remember why I

would do that, but that's clearly not the way to close a ticket. Sorry for that.

Ah, well, I suppose sometimes we get in a hurry. Or distracted by something else that's shiny and interesting. Heh.

...

The problem with the message queue is that it won't work at all in Linux between 32 and 64 bit processes because this message queue is based on process-shared mutex and condition variables and pthread mutex and condition variables provided by glibc are not compatible between 32 and 64 bit processes.

Ugh. I do want something that will work well on Linux as well. I've

learned that Linux, like Windows, can accommodate processes in either 32-bit or 64-bit architectures on a 64-bit machine. If my employer wants to support 64-bit systems (and I think they do, if not immediately), they must consider this issue.

The alternative to have a portable message queue is to implement it over POSIX message queues (which uses system calls) on Unix systems and implement a similar interface over Windows named pipes or similar. Not trivial to achieve.

In general I regret putting message_queue in Interprocess, as IMHO it's not good enough to be in the library. Some people find it useful, though.

It's still useful for my needs, just not quite as elegant as I would like. I can successfully deliver information across platforms in a relatively simple fashion. I just have to use two different servers for that purpose. I am tempted, now, to try and build one that does what I want. I can either do this using the time I spend working towards my needs at my job, or I can try to do this at home, where I can then freely donate the code to boost if the community deems it worthy. I don't think I'm the only person who needs this, given that someone else wrote that defect. I have a lot to learn, though. In any event, thank you very much for your thoughtful response. It gives me much to consider. - Trey

El 19/06/2014 16:20, Andrey Semashev escribió:

On Thu, Jun 19, 2014 at 12:56 AM, Ion Gaztañaga wrote:

...

The problem with the message queue is that it won't work at all in Linux between 32 and 64 bit processes because this message queue is based on process-shared mutex and condition variables and pthread mutex and condition variables provided by glibc are not compatible between 32 and 64 bit processes.

Interesting. Do you think it is possible to use futexes directly to implement this portability? This would be a Linux-specific solution, of course.

Futexes take a int pointer and in Linux int is 32 bits in both 32 and 64 bit processes (I think it uses the LP64 data model). So yes, that would be possible, but quite hard to implement, as futexes are quite tricky. I would accept patches, though ;-) We can also test if using spin_condition/spin_mutex is enough from a performance point of view. Those are implemented with basic atomic operations and waits, but operating in 32 bit integers. That could be portable in all OS if correct alignments are used. Best, Ion