Thought I'd start a thread here about DBIx::Class and threads, and specifically the issue raised by Ryan Parr on the Catalyst mailing list about mpm_winnt threads compatibility. Apparently under such scenarios, we can treat the case just like we treat things if someone was manually using ithreads in their perl code and using DBIx::Class.
The issue here is that DBIx::Class[::Storage::DBI] really is already thread-safe (for that matter it was already fork-safe before the fork changes too). It's DBI.pm's lack of fork/thread-safety that we're working around there (which is why the standard ithreads advice about how to make thread-safe modules without explicitly "use threads" doesn't apply). We cannot see thread changes without "use threads" to get at "threads->tid" and handle it like the fork stuff. But if the calling code isn't using threads, we shouldn't be doing "use threads" (especially if the perl in question doesn't even support threads). Basically, we want the connection routines in Storage::DBI to make use of the thread id returned by "threads->tid", but if and only if we're running under a threaded perl (can use Config.pm to see that), and if and only if the application that's using us already did "use threads" (because we shouldn't "use threads" if they didn't). I'm guessing we can see that by checking %INC for "threads"? Make both checks in a BEGIN block and decide whether to "require threads;" and set some flag for the connection code to later know that it can safely check thread id's? Thoughts on any of this from anyone that knows more about ithreads? -- Brandon _______________________________________________ List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class Wiki: http://dbix-class.shadowcatsystems.co.uk/ IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/
