[zeromq-dev] Issue 85 & 92

Pieter Hintjens ph at imatix.com
Sat Oct 16 16:58:59 CEST 2010

On Sat, Oct 16, 2010 at 4:42 PM, Martin Sustrik <sustrik at 250bpm.com> wrote:

> Anyway, the "exotic programs" means basically any language runtime. I am not
> sure that Oracle would modify it's Java VM or that MSFT would tweak .NET
> runtime just to work well with 0MQ.

I'm not sure you're seriously saying the problem lies with language
runtimes.  If so, please be explicit, this is hard enough to follow
without the goal posts picking up and running around the field as

> Not even that. The problem is that while you may be notified about the
> migration of the socket to the OS thread executing zmq_term, you cannot
> directly touch it as you have no guarantee that it won't be migrated to a
> different OS thread afterwards.

We know that socket migration is a specialized use case and language
bindings or exotic programs that do it can be asked to do extra work,
that's fine for everyone IMO.

I'm not sure what you mean by "touch it".  What's 'it'?  Socket, thread?

What migrates the socket?  The runtime, or the language binding?  Why
do you care if it's migrated afterwards?  How does this relate to the
inability of a thread to know it's talking to itself?

Are you saying (because it's quite hard to follow you) that if we
never migrated sockets, zmq_term would not have to block?  Can we thus
allow this to work correctly for the 99.99% of programs that will
never migrate sockets?


More information about the zeromq-dev mailing list