[zeromq-dev] Bad file descriptor in rm_fd()

[MinRK]

125 consecutive test runs without failure and counting.  Thanks guys!


On Wed, Nov 6, 2013 at 8:52 AM, Pieter Hintjens <pieterh at gmail.com> wrote:

> Ric, this is great! I'll backport the fix to 3.2 and 4.0 once MinRK
> confirms it.
> On Nov 6, 2013 4:55 PM, <Richard_Newton at waters.com> wrote:
>
>>  Well, hopefully I haven't broken anything, it looks OK to me.
>>
>> For the record, a way I found to make this trigger every time is to put a
>> 1 second sleep between the unlock and the relock, and a 0.5 second sleep at
>> the start of reaper_t::process_reaped (without the delay in
>> process_repeaped the second stop gets sent but the mailbox gets closed
>> before its processed).
>>
>> Ric.
>>
>>
>> [image: Inactive hide details for "Pieter Hintjens" ---06/11/2013
>> 03:45:28 PM---On Wed, Nov 6, 2013 at 4:31 PM, <Richard_Newton at waters.]"Pieter
>> Hintjens" ---06/11/2013 03:45:28 PM---On Wed, Nov 6, 2013 at 4:31 PM, <
>> Richard_Newton at waters.com> wrote: >
>>
>> From: "Pieter Hintjens" <ph at imatix.com>
>> To: "ZeroMQ development list" <zeromq-dev at lists.zeromq.org>,
>> Date: 06/11/2013 03:45 PM
>> Subject: Re: [zeromq-dev] Bad file descriptor in rm_fd()
>> Sent by: zeromq-dev-bounces at lists.zeromq.org
>> ------------------------------
>>
>>
>>
>> On Wed, Nov 6, 2013 at 4:31 PM, <Richard_Newton at waters.com> wrote:
>> >
>> > OK, so investigating this, I think
>> https://github.com/zeromq/libzmq/pull/738 may solve the issue.
>> >
>> > What I think is happening is ctx_t::terminate, we set the state to
>> terminating then immediately unlock and relock the slot_sync lock.
>> >
>> > If the last destroy_socket gets in while we are brief unlocked, both
>> destroy_socket and terminate will issue a reaper->stop (), so we will call
>> process_stop twice.
>> >
>> > Anyone know why we do the unlock/relock dance?
>>
>>
>> I'd guess this was an attempt by Sustrik to make the shutdown work
>> properly. It's always been a difficult part of the design.
>>
>> -Pieter
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
>> ===========================================================
>> The information in this email is confidential, and is intended solely for the addressee(s).
>> Access to this email by anyone else is unauthorized and therefore prohibited.  If you are
>> not the intended recipient you are notified that disclosing, copying, distributing or taking
>> any action in reliance on the contents of this information is strictly prohibited and may be unlawful.
>> ===========================================================
>>
>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131106/ebe64ad0/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20131106/ebe64ad0/attachment.gif>