Hi Daisuke,

You can create and destroy contexts in a test case like that, as long
as you're aware that these are separate 0MQ instances that can't
communicate over inproc:.

Forking is something we didn't cover yet in the Guide.  You cannot
create a context and pass it to a child process.  The proper model is
to fork first, and create the 0MQ context afterwards in each process
as needed.  If a parent forks off children after creating a 0MQ
context, the children can't use it, and should create their own.

Martin, can you confirm that this is accurate?

-Pieter


On Tue, Sep 14, 2010 at 10:32 AM, Daisuke Maki <lestr...@gmail.com> wrote:
> My tests do this in the same file:
>
>   { # test case 1
>       my $ctxt = ZeroMQ::Context->new(); # internally calls zmq_init();
>       ... test code here ....
>   } # contxt freed
>
>   { # test case 2
>       my $ctxt = ZeroMQ::Context->new(); # internally calls zmq_init();
>       ... test code here ....
>   } # contxt freed
>
> should this work?
>
> And how about when you fork?
> Who should own the context? the parent? the child? or should it be shared?
>
> --d
>
> 2010/9/14 Martin Sustrik <sust...@250bpm.com>:
>> Hi Pieter,
>>
>> One frequent misuse of 0MQ is that newbies tend to open multiple context
>> objects with no apparent reason.
>>
>> What about explaining the correct usage in the user guide?
>>
>> The _only_ use case for multiple contexts is this one:
>>
>> Person A writes a library using 0MQ. Person B writes another library
>> using 0MQ. Person C links both libraries to his application. If each
>> haven't had a separate context the two 0MQ instances would clash. Name
>> clashes in the shared namespace for inproc endpoints. How many I/O
>> threads to launch, A's amount or B's amount? etc.
>>
>> In short: If you are writing an application use _one_ context object.
>> Another context object can arrive in the process only by linking with a
>> different application.
>>
>> Martin
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>
>



-- 
-
Pieter Hintjens
iMatix - www.imatix.com
_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev

Reply via email to