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

Ben Craig commented on THRIFT-2441:
-----------------------------------

-1 for this specific fix.  Closing a socket that is currently in use results in 
undefined behavior.  Even worse... it will usually work (as has been observed).

Here is a scenario that I've run into when others have used this pattern.  I've 
had to fix this in real code, it is not just a hypothetical.

Thread 1 is the primary thread dealing with a socket.  This socket happens to 
have the value 42.  At this exact moment, it is just about to call recv on the 
socket, but the function call hasn't happened yet.

Thread 2 calls close on socket 42.

Thread 3 (the listen / accept thread) gets a new connection.  It assigns this 
new connection a socket, and it gives this new socket the number 42.

Thread 1 finally invokes recv, but not on the connection that it wanted, but on 
a connection it basically stole from elsewhere.  The two sockets only happened 
to have the same numeric value.



The correct way to fix this involves calling something like select() before 
every recv().  The select() call is watching both the socket of interest, as 
well as a control socket.  When you want to tear down the threaded server, you 
push a byte into the control socket to wake up all the worker threads.  The 
worker threads can then see some boolean 'isDead' flag and tear down.

This approach does cost an extra system call on every recv(), and it requires 
an extra socket_pair().  But it doesn't have data corruption issues.

> Cannot shutdown TThreadedServer when clients are still connected
> ----------------------------------------------------------------
>
>                 Key: THRIFT-2441
>                 URL: https://issues.apache.org/jira/browse/THRIFT-2441
>             Project: Thrift
>          Issue Type: Bug
>          Components: C++ - Library
>    Affects Versions: 0.9.1
>            Reporter: Chris Stylianou
>            Assignee: Roger Meier
>
> When calling stop() on the TThreadedServer no interrupts are sent to the 
> client threads. This means the stop() call blocks on tasksMonitor.wait() 
> until all client naturally disconnect.
> How can we tell the client thread connections to close/exit during the 
> TThreadedServer::stop() call?



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

Reply via email to