[jira] [Comment Edited] (THRIFT-3891) TNonblockingServer configured with more than one IO threads does not always return from serve() upon stop()

["Buğra Gedik (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/THRIFT-3891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15657456#comment-15657456 ] 

Buğra Gedik edited comment on THRIFT-3891 at 11/11/16 4:30 PM:
---------------------------------------------------------------

Hi [~jking3]. Since you worked on THRIFT-3932, I was wondering if you would be interested in taking a look at this one as well. This is another threading issue we've had to patch ourselves. Or perhaps you know someone who is familiar with this part of the code, who can take a look at this.


was (Author: bgedik):
Hi [~jking3], since you worked on THRIFT-3932, I was wondering if you would be interested in taking a look at this one as well. This is another threading issue we've had to patch ourselves. Or perhaps you know someone who is familiar with this part of the code, who can take a look at this.

> TNonblockingServer configured with more than one IO threads does not always return from serve() upon stop()
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: THRIFT-3891
>                 URL: https://issues.apache.org/jira/browse/THRIFT-3891
>             Project: Thrift
>          Issue Type: Bug
>          Components: C++ - Library
>    Affects Versions: 0.9.3
>            Reporter: Buğra Gedik
>            Priority: Minor
>         Attachments: patch.diff
>
>
> Using {{TNonblockingServer}}, when the number of IO threads is > 1, there is race condition in which {{stop()}} does not properly unblock {{serve()}}. 
> The problem manifests itself when {{stop()}} is called (obviously from a different thread) soon after {{serve()}}. 
> The core issue is that, {{event_base_loopbreak()}} is called within the {{stop()}} sequence without checking whether the IO thread has actually entered its event loop. The documentation of {{event_base_loopbreak()}} says (http://www.wangafu.net/~nickm/libevent-book/Ref3_eventloop.html)
> {quote}
> Note also that event_base_loopexit(base,NULL) and event_base_loopbreak(base) act differently when no event loop is running: loopexit schedules the next instance of the event loop to stop right after the next round of callbacks are run (as if it had been invoked with EVLOOP_ONCE) whereas loopbreak only stops a currently running loop, and has no effect if the event loop isn’t running.
> {quote}
> Attached is a patch (against the released 0.9.3 version of the codebase).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)