I have an application in which I am blocking on a TCP Socket read through a persistence engine in one thread and trying to write through a different persistence engine using the same socket in a second thread. This results in an application deadlock.
I am building on RH Linux 6.2 using the revs of GCC and glib present on the RH distribution.
My best guess is that the pthreads library is using user threads and not kernel threads. Is there something else I am missing and/or is there a way to determine the threading model?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In my test case, I have a class Pipe which extends Thread and which pipes data from an istream to an ostream, like so:
virtual void Run (void) {
char c;
while (is.get(c)) os.put(c).flush();
}
A single such Pipe from cin to a TCPStream works fine. Likewise, a Pipe from a TCPStream to cout works fine.
If I use two Pipes, one from cin to a TCPStream and one from that same TCPStream to cout, the latter seems to work regardless, but the former locks up after reading a single character from cin, which seems to indicate that there is some sort of lockup in the TCPStream::write() method. The threads themselves appear to work fine, and I know that my application is not blocked (the main program thread can continue to function).
Are there thread-safety issues with the TCPStream class, perhaps?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have had similar problems: while doing a blocking read on a socket, and writing to the socket at the same time, neither of the actions takes place (tried on 1.4.2 last time). The problem was (non-foolproofly) solved by polling the socket before entering the read operation. This would (kinda) prove the thread-safety issues with TCPStream.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have an application in which I am blocking on a TCP Socket read through a persistence engine in one thread and trying to write through a different persistence engine using the same socket in a second thread. This results in an application deadlock.
I am building on RH Linux 6.2 using the revs of GCC and glib present on the RH distribution.
My best guess is that the pthreads library is using user threads and not kernel threads. Is there something else I am missing and/or is there a way to determine the threading model?
This sounds more like a socket deadlock issue than a thread deadlock issue. Perhaps you are filling up the socket receive/socket send buffers?
I am actually having a similar problem on my end.
In my test case, I have a class Pipe which extends Thread and which pipes data from an istream to an ostream, like so:
virtual void Run (void) {
char c;
while (is.get(c)) os.put(c).flush();
}
A single such Pipe from cin to a TCPStream works fine. Likewise, a Pipe from a TCPStream to cout works fine.
If I use two Pipes, one from cin to a TCPStream and one from that same TCPStream to cout, the latter seems to work regardless, but the former locks up after reading a single character from cin, which seems to indicate that there is some sort of lockup in the TCPStream::write() method. The threads themselves appear to work fine, and I know that my application is not blocked (the main program thread can continue to function).
Are there thread-safety issues with the TCPStream class, perhaps?
That should be the TCPStream::put() method, not the TCPStream::write() method. :)
Duh... Can't block two threads on the same file descriptor. Use dup() to duplicate the file descriptor, then input from one and output to the other.
Can this be implemented in TCPStream? (Or has it already been implemented?)
I have had similar problems: while doing a blocking read on a socket, and writing to the socket at the same time, neither of the actions takes place (tried on 1.4.2 last time). The problem was (non-foolproofly) solved by polling the socket before entering the read operation. This would (kinda) prove the thread-safety issues with TCPStream.