[rabbitmq-discuss] AMQP & Python Write-Up
0x6e6562 at gmail.com
Wed Jan 14 23:12:52 GMT 2009
On Wed, Jan 14, 2009 at 11:04 PM, Tim Coote <tim+rabbitmq.com at coote.org> wrote:
> Surely one of the great benefits of a messaging programming style is
> that you can use processes rather than threads.
> Threads will surely become a bottleneck as future hardware speed
> improvements move to multicore and so cannot support shared state. So,
> we can move back to the relatively safer and lower cost ($ to build
> and maintain) process based software models.
> Although Python supports a threading model, the GIL makes it
> ineffective in many cases. I suspect that this is deliberate on
> Guido's part.
Be that as it may, the central tenant is to not interleave different
command streams in one channel.
Whether this is done by thread or process confinement (or even if you
are a kernel hacker and you know that in reality there is no such
thing as a thread or a process) is irrelevant.
The broker has no visibility into what client side objects are shared,
nor does it care.
The broker is just sitting on the other end of a wire with the mere
expectation that each individual stream of commands is stateful and
More information about the rabbitmq-discuss