On Jul 18, 2012, at 2:49 AM, moteus wrote:
> Chuck Remes chuckremes.com> writes:
>
>
>> Oh, so the threads are short-lived then. In that case, you should create a
> pool of them and have each thread
>> "check out" the socket from the pool when it needs to use it and check it
>> back
> in again
Chuck Remes chuckremes.com> writes:
> Oh, so the threads are short-lived then. In that case, you should create a
pool of them and have each thread
> "check out" the socket from the pool when it needs to use it and check it back
in again when the thread exits.
> If the pool is protected by a mech
On Jul 17, 2012, at 9:14 AM, moteus wrote:
> Chuck Remes chuckremes.com> writes:
>
>> You should create only ONE context. The context can be passed to each thread;
> any socket you create in a
>> thread should only be used from that thread.
>>
>> I recommend that you read the guide and the FAQ.
Chuck Remes chuckremes.com> writes:
> You should create only ONE context. The context can be passed to each thread;
any socket you create in a
> thread should only be used from that thread.
>
> I recommend that you read the guide and the FAQ. These ideas are discussed in
both places.
>
> cr
>
On Jul 17, 2012, at 6:27 AM, moteus wrote:
> Hi.
>
> I have some service.
> Service creates new thread for each request and call function from .dll to
> proceed this request.
> I write only .dll and can not change service.
> What best method to use REQ/REP sockets over inproc and tcp.
> If I und
Hi.
I have some service.
Service creates new thread for each request and call function from .dll to
proceed this request.
I write only .dll and can not change service.
What best method to use REQ/REP sockets over inproc and tcp.
If I understood correctly i have to create new context (tcp) and soc
