You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Kevin Ballard (JIRA)" <ji...@apache.org> on 2008/05/27 01:45:57 UTC
[jira] Created: (THRIFT-21) TThreadPoolServer has dangerous
thread-safety issue in accepting connections
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.
[jira] Commented: (THRIFT-21) TThreadPoolServer has dangerous
thread-safety issue in accepting connections
Posted by "Kevin Ballard (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Closed: (THRIFT-21) TThreadPoolServer has dangerous
thread-safety issue in accepting connections
Posted by "Kevin Clark (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kevin Clark closed THRIFT-21.
-----------------------------
Resolution: Won't Fix
Sounds like this is taken care of. If it's not, we'll reopen.
> 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.
[jira] Commented: (THRIFT-21) TThreadPoolServer has dangerous
thread-safety issue in accepting connections
Posted by "Kevin Ballard (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603739#action_12603739 ]
Kevin Ballard commented on THRIFT-21:
-------------------------------------
I'm going to go ahead and say this is a non-issue. I find it perfectly believable that all modern OS's do in fact implement accept() in a thread-safe manner, and even if that is not the case, ThreadPoolServer is going to be obsoleted by NonblockingServer very shortly.
> 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.
[jira] Commented: (THRIFT-21) TThreadPoolServer has dangerous
thread-safety issue in accepting connections
Posted by "David Reiss (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12599933#action_12599933 ]
David Reiss commented on THRIFT-21:
-----------------------------------
I Googled around for this a bit and found this <http://books.google.com/books?id=tdsZHyH9bQEC&pg=PA785&dq=thread-safe+accept&ei=DlA7SNbbH4PitgPN2tmdAw&client=firefox-a&sig=AnRQunQLb4lcMvlxiCVI-HvjijA>, which states that accept is defined to be thread-safe (which I verified) but that not all OSes comply with this (which I did not verify). If anyone can find an example of an OS that we want to support that does not provide a thread-safe accept, I think we should consider implementing a workaround.
> 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.