in reply to MultiThread possible issues - basic questions - Thanks

Answers:
  1. I'm inclined to trust DBI. 2 reasons. One, I'm still a little dubious about the stability of Perl's threading. Two (and more importantly), even if Perl's threading model is fine, any binary module that you load may or may not be threadsafe. Odds are that the DBI authors are suggesting that either DBI or the DBD::* driver that you use may not be threadsafe. I wouldn't dismiss that.
  2. I don't know the reason for this. rob_au's theory sounds as good as any.
  3. That wasn't a question, so I'm not answering it. ;-)
  4. Part of the answer is "no", part is "yes", and part is "maybe". Any externally allocated interactions (eg with a database) may or may not get cleaned up properly when you just go. Any internal memory allocation should get cleaned up when you go. As for who dies, I think that that depends on the threading model that the operating system uses. In particular do all threads share the same process ID or not? Different implementations of POSIX threads differ on this. I suspect that the version that you get on Solaris by default is one of the threading models where you can have multiple process IDs per thread, which suggests that you may only kill some of your threads. But read the documentation on your operating system's threading model before quoting me on a vague memory about something that I haven't worked with.
  5. Yes. If multiple database handles share a socket, then the database has no way to sort out what is happening when multiple threads babble simultaneously on that socket. So each thread needs its own socket and hence its own database handle.
  6. The code that you have written is not all Perl. For instance // is not a comment, and If Failure Then... is some other language entirely. Beyond that, my big concerns are internal to DBI, and what might happen in things like calls to do_job. (eg If you spawn threads there, then you have trouble.)

In Section Seekers of Perl Wisdom