in reply to Re^2: Can't locate object method ""
in thread Can't locate object method ""

I was specifically using "require" since it is runtime. Whether it is actually required depends on configuration. The input or output files may be fixed-width, and I didn't want to load Text::CSV_XS unless it was actually needed. I also didn't want to have modules loaded in more threads than needed, although I couldn't avoid having threads created by the input thread inheriting it if the input file is delimited.

I figured it had to do with garbage collection, because in my actual script, it would only happen on the last chunk of queued data, so I figured after the input file was closed and no longer referenced. I began suspecting it was related to Text::CSV_XS because it only happened with delimited files when that module was used.

I hadn't known that modifying the GST in a thread was bad. Is that documented? I thought everything global for a thread was essentially copied from the parent, and I was trying to minimize what would be copied.

I appreciate your help! I was hoping to confirm that requiring the module globally before creating threads would eliminate the issue, since I can't have intermittent crashes in production. I wouldn't want to sacrifice performance by using Text::CSV_PP instead, though. I created a bug report.

Replies are listed 'Best First'.
Re^4: Can't locate object method ""
by huck (Prior) on Dec 22, 2016 at 03:39 UTC

    "I hadn't known that modifying the GST in a thread was bad. Is that documented? "

    After further research im not sure where that idea came from, possibly mixing up in my head the 5.005 threads and the 5.8+ ithreads. In my head it was things that disappeared in or changed memory pointers in the GST in one thread could mess with other threads that used the same variable. But recent reading supports the idea that there are no perl shared memory spaces between the GSTs in different threads