[
https://issues.apache.org/jira/browse/THRIFT-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599935#action_12599935
]
Kevin Ballard commented on THRIFT-21:
-------------------------------------
The "standard" workaround, so to speak, is to do the accepting in the main
thread and then hand the socket off to the worker thread. This can be achieved
by blocking on select() instead of on the SizedQueue. This is also something
that I'm planning on doing with my rewrite, because another goal is to make the
threaded server more fair, by using method invocation as the unit of work
instead of the lifetime of the client (in other words, after each exchange, the
socket will be thrown back into the queue so long-lived client connections
won't prevent other clients from connecting).
> TThreadPoolServer has dangerous thread-safety issue in accepting connections
> ----------------------------------------------------------------------------
>
> Key: THRIFT-21
> URL: https://issues.apache.org/jira/browse/THRIFT-21
> Project: Thrift
> Issue Type: Bug
> Components: Library (Ruby)
> Reporter: Kevin Ballard
>
> TThreadPoolServer currently accepts incoming connections in threads. This
> means that at any time, as long as the thread pool is not completely full of
> running connections, there are multiple threads currently blocking on the
> #accept call. This is dangerous because the accept syscall is not documented
> as being thread-safe. The only reason this actually works in ruby is because
> of the cooperative threading, but if this library is used in any ruby
> interpreter that supports native threads (e.g. MacRuby, jruby, etc) I would
> expect it to start manifesting strange bugs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
