{"action":"created","issue":{"url":"https://api.github.com/repos/nanomsg/nanomsg/issues/449","labels_url":"https://api.github.com/repos/nanomsg/nanomsg/issues/449/labels{/name}","comments_url":"https://api.github.com/repos/nanomsg/nanomsg/issues/449/comments","events_url":"https://api.github.com/repos/nanomsg/nanomsg/issues/449/events","html_url":"https://github.com/nanomsg/nanomsg/pull/449","id":100461961,"number":449,"title":"Address issue #446","user":{"login":"qbradley","id":938483,"avatar_url":"https://avatars.githubusercontent.com/u/938483?v=3","gravatar_id":"","url":"https://api.github.com/users/qbradley","html_url":"https://github.com/qbradley","followers_url":"https://api.github.com/users/qbradley/followers","following_url":"https://api.github.com/users/qbradley/following{/other_user}","gists_url":"https://api.github.com/users/qbradley/gists{/gist_id}","starred_url":"https://api.github.com/users/qbradley/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/qbradley/subscriptions","organizations_url":"https://api.github.com/users/qbradley/orgs","repos_url":"https://api.github.com/users/qbradley/repos","events_url":"https://api.github.com/users/qbradley/events{/privacy}","received_events_url":"https://api.github.com/users/qbradley/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":11,"created_at":"2015-08-12T04:21:30Z","updated_at":"2015-08-14T04:17:30Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/nanomsg/nanomsg/pulls/449","html_url":"https://github.com/nanomsg/nanomsg/pull/449","diff_url":"https://github.com/nanomsg/nanomsg/pull/449.diff","patch_url":"https://github.com/nanomsg/nanomsg/pull/449.patch"},"body":"This addresses issue #446.\r\n\r\nUse a global mutex instead of a global event to protect the file descriptor creation on Windows.\r\nAn acquired mutex will be released when the thread that owns it exits without releasing the mutex explicitly, for example when a process is terminated.\r\nThe caveat is that any other process waiting for the mutex will get WAIT_ABANDONED instead of WAIT_OBJECT_0 returned from WaitForSingleObject. However, the mutex will be acquired by the previously waiting process. This is documented here near the remarks on WAIT_ABANDONED return value: https://msdn.microsoft.com/en-us/library/windows/desktop/ms687032\r\n\r\nI tested this change by running the unit tests.\r\nI further tested it by running \"nanocat --req --bind tcp://127.0.0.1:8000 --data abcd -Q\" instrumented to delay while the mutex was held. I terminated the one that had acquired the mutex and observed the other process continue seeing the WAIT_ABANDONED return code."},"comment":{"url":"https://api.github.com/repos/nanomsg/nanomsg/issues/comments/130959964","html_url":"https://github.com/nanomsg/nanomsg/pull/449#issuecomment-130959964","issue_url":"https://api.github.com/repos/nanomsg/nanomsg/issues/449","id":130959964,"user":{"login":"qbradley","id":938483,"avatar_url":"https://avatars.githubusercontent.com/u/938483?v=3","gravatar_id":"","url":"https://api.github.com/users/qbradley","html_url":"https://github.com/qbradley","followers_url":"https://api.github.com/users/qbradley/followers","following_url":"https://api.github.com/users/qbradley/following{/other_user}","gists_url":"https://api.github.com/users/qbradley/gists{/gist_id}","starred_url":"https://api.github.com/users/qbradley/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/qbradley/subscriptions","organizations_url":"https://api.github.com/users/qbradley/orgs","repos_url":"https://api.github.com/users/qbradley/repos","events_url":"https://api.github.com/users/qbradley/events{/privacy}","received_events_url":"https://api.github.com/users/qbradley/received_events","type":"User","site_admin":false},"created_at":"2015-08-14T04:17:30Z","updated_at":"2015-08-14T04:17:30Z","body":"I have updated my branch with a proposed fix.\r\n\r\nWhat I meant by ignoring was to not continue with execution but return from the handler. There is no work to do for a pipe event when in the stopping state.\r\n\r\nThe subsequent code should only be executed for an event originating from the endpoint when in the stopping state.\r\n\r\nI added an assert and a comment to make what I believe to be the correct intention of the code more clear.\r\n\r\nLet me know what you think."}}