[zeromq-dev] Issue 85 & 92

[Martin Sustrik]

On 10/16/2010 04:58 PM, Pieter Hintjens wrote:
> 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.
>    
Nope. Bindings can't. They are not notified about the migration by the 
runtime. The runtime simply moves the socket from app thread to gc 
thread. That's it. No notification. You would have to modify the runtime.

> I'm not sure what you mean by "touch it".  What's 'it'?  Socket, thread?
>    
The data inside the socket. Member variables etc.
> What migrates the socket?  The runtime, or the language binding?
The runtime.
>    Why
> do you care if it's migrated afterwards?
Two threads accessing same data without locking ==> disaster.

>    How does this relate to the
> inability of a thread to know it's talking to itself?
>    
if (get_thread_id (this_thread) == get_thread_id (sock))
{
     //  sock is migrated to a different thread here behind the scenes.

     //  directly modify sock's data from this thread
     sock->some_variable = some_value;

    //  crash!
}
> 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?
>    
Almost all language runtimes do migrate sockets. Thus you have say 80% 
programs affected.

Martin