On 05/31/2012 02:50 AM, Roger Oberholtzer wrote:
On 05/30/2012 10:46 AM, Roger Oberholtzer wrote:
On 05/30/2012 03:39 AM, Roger Oberholtzer wrote: " If a process starts a thread, and that thread exits, the process does not know about this until it tries to join the thread, right?"
Not entirely true. There are a number of ways to allow a thread to exit avoiding the need to join. It has been a few years since I was working with pthreads, but you can set up a thread as detached. The main issue you need to understand is that unlike processes, threads run in the context of the thread creator. So, a segv in a thread will cause the entire process to fail. One of the things that really helps in thread programming is exception processing and try blocks. By wrapping sections of your code in try blocks you can avoid this nastiness. Additionally, if you have multiple child threads. Additionally I always recommend my former coworker, Dave Butenhof's books. The 'fun' I am having is that in the past few months, three equipment suppliers have provided a Linux interface to their hardware. Generally
On Wed, 2012-05-30 at 09:43 -0400, Jerry Feldman wrote: this should be considered a good thing. All are implemented by starting threads. For two of the suppliers (GigE Vision cameras) I do not have the source and so cannot determine if they are doing things in the safest fashion. I really like threads and see that our application benefits from them greatly. We have used them for a couple years, But when something goes wrong. and especially if it is in a black box bit of code, life gets tedious.
"life gets tedious" Naw, fun :-)
Thread debugging can be challenging. You can use some tools, like gdb. I'm not sure, but IBM Rational's Purify was able to debug threads on some platforms. I've never used Purify on Linux, only on Digital/Compaq Tru64 Unix. However, you can still add try blocks to their code to help a bit. Thread debugging. though, can provide a lot of challenges. The first thing you need to know is if their code is thread-safe. One would imagine threaded code to be thread-safe. At least in intention, it not in reality. For the suspect libraries, I do not have
On Wed, 2012-05-30 at 11:55 -0400, Jerry Feldman wrote: the source.
The symptom I see is that when I use one of these libraries, I then get a segmentation violation in libz. And I cannot see any problem with my call to gzwrite(). I am guessing that some part of the zlib data structure for the specific file has been corrupted by someone. The failure is always at the same point: a SIGPOLL signal results in a signal handler reading from a GPS, and the read data is sent to gzwrite(). The reads/writes are properly serialized. The signals do not interrupt themselves. When I add the thread library to the application so that there are threads reading from GigE Vision cameras, this problem can occur.
If I don't enable the GPS reader, I do not get a failure. I suspect a memory corruption still occurs, but at some place that is 'innocent'.
Basically, signal handlers are not threadsafe. I would probably guess that libz itself is not threadsafe. Additionally most of libc++ is also not threadsafe. Lots of discussions online about this. You just need to remember that threads run in the context of the user, and signal handlers run in the context of root. If you are sharing memory with memory used by the signal handler you are in very dangerous territory. -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix PGP key id:3BC1EB90 PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66 C0AF 7CEA 30FC 3BC1 EB90