Linked by Hadrien Grasland on Fri 27th May 2011 11:34 UTC
Permalink for comment 475059
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Features
Linked by Thom Holwerda on 05/24/13 17:26 UTC
Linked by Thom Holwerda on 05/21/13 21:38 UTC
Linked by Thom Holwerda on 05/20/13 11:29 UTC
Linked by Thom Holwerda on 05/18/13 21:33 UTC
Linked by David Adams on 05/16/13 4:23 UTC
Linked by Thom Holwerda on 05/11/13 21:41 UTC
Linked by Thom Holwerda on 05/08/13 14:22 UTC
Linked by Thom Holwerda on 05/02/13 15:28 UTC
Linked by Thom Holwerda on 04/29/13 21:06 UTC
Linked by Thom Holwerda on 04/24/13 22:24 UTC
More Features »
Sponsored Links



Member since:
2005-11-16
Hi,
Why need there be any limit at all, short of memory constraints or policy?
There doesn't need to be any hard limit.
In practice, if the limit is too small you end up splitting data into many messages and combining the pieces at the receiving end (and possibly pounding the daylights out of the kernel); and if the message size is too big (or unspecified/unlimited) it's hard to tasks to reserve space for receiving messages, and you risk running out of RAM (e.g. all your free RAM gets tied up in messages in queues).
There's also compatibility issues. For example, imagine a 64-bit kernel capable of running 64-bit processes and 32-bit processes. With no limit, what happens when a 64-bit process sends a 12 GiB message to a 32-bit process?
Locally delivered messages can be guarantied, network messages would depend on the underlying protocols - but how is this any different between threads/async?
Locally delivered messages may not be guaranteed to be received. You send a message to a task, it's placed in that task's queue, then that task terminates or crashes before it gets your message from its queue.
It's using asynchronous messaging and multiple threads; so I'm not sure if that's different to whatever you think "threads/async" is... ;-)
A queued async model doesn't get out of sequence messages, so I'm not sure why your asking this question?
Imagine 3 tasks. Task A sends a message to task B and then sends a message to task C. When task C receives the message from Task A, it sends a message to task B. Can task B receive the message from task C before it receives the message from task A?
In some cases the answer is "yes" - mostly when there's some sort of intermediate buffering/queuing happening before the message reaches the final task's queue (e.g. in networking layers).
- Brendan