From: Dmitry Smirnov (basilisk_at_[hidden])
Date: 2006-07-10 07:09:23
>>But at the current moment I'm very interesting in adding of more
>>features to shared_message_queue class. As I understood this queue
>>supplies only one client-server connection. So one message can be
>>received only one time despite of many processes that want to read it.
>>It seems to have internal client number counter will be a good idea.
> You want the queue to have an internal client number so that a message
> should be read N times before it's removed from the queue? I've based my
> model on POSIX mq_xxx functions that offer this possibility. I a
> reference counted message quite dangerous because a process crash would
> block the queue indefinitely. I don't see an strong reason to do this.
> If you want a robust server<->multi-client communication, I would create
> N message queues just like a web server has a connection with each web
> client. If a client crashes, the server and the other clients are still
> fine. If a timeout expires you could even erase the used message queue
> system wide erasing the shared memory that was used for that message
> queue. This multiplies the number of sent/received messages, and makes
> the application more complicated, though.
You're right understand what I want. And no matter how it will be
realized. It's interesting but you said practically the same idea as I
made in my application short time ago. In every message I put the name
of SHM object and kill this object after some timeout despite of it was
object processed or not.
I'm waiting new versions in anticipation ! :-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk