>As to why your code fails? I suspect the use of an XS module that doesn't support multithreading.
I am not confident that this is correct. Based on my understanding if ithreads, it's not traditional light weight threads (e.g., pthreads), so there is no possibility of the threadsafeness of the shared library being tested. The ideal of threadded shared libraries is certainly interesting and I think appropriate if implemented carefully in the library with mindfulness that it's going to be used by a single perl parent process and perl datastructures are in no way thread safe.
There seems to be a severe lack of familiarity in the Perl community with what "real" threads are wrt "multithreading". No doubt this is not lost of many, but I continue to see over and over again the suggestion that Perl ithreads are related to traditional shared memory threads. This is simply not the case.
The suggestion that Perl ithreads should not be used on Windows also seems to contradict the author of Coro's explaination (in POD of Coro) of what Perl threads are, and based on my knowledge of threads he "gets it". In fact, he indicates that ithreads is actually appropriate to some degree for Windows but completely brain dead for *nix/POSIX platforms.
I offer the above simply to prevent the spread of false information, I am open to being wrong and would appreciate constructive correction in any form. | [reply]
[d/l]
[select] |
I can't make heads or tails of anything you are saying. These three points should handle it all, though:
Perl uses real threads (pthread_create where available).
Thread-safe XS libraries are possible, and many are. But supporting multi-threading may require extra work. (This isn't specific to XS.) For example, JSON::XS isn't thread safe (because its author intentionally refuses to support them on principle), but Cpanel::JSON::XS is.
There's nothing wrong with using threads in unix.
If you want to perform aynchronous operations, Coro is one of many useful approaches. Just beware that if any of your Coro threads use something that's incompatible with the event loop being used by Coro, everything will block since it's a co-operative multi-tasking system.
If you want parallel processing, you'll need OS-level tasks (e.g. threads or processes), not what Coro provides.
Update: I meant "that's incompatible". Fixed.
| [reply]
[d/l] |
>>As to why your code fails? I suspect the use of an XS module that doesn't support multithreading.
>I am not confident that this is correct. Based on my understanding if ithreads, it's not traditional light weight threads (e.g., pthreads), so there is no possibility of the threadsafeness of the shared library being tested. ...
From the threads documentation:
Since Perl 5.8, thread programming has been available using a model called *interpreter threads* which provides a new Perl interpreter for each thread, and, by default, results in no data or state information being shared between threads.
So, perl threads are just a thin layer over the C interface to the OS implementation of threads, with the heavyweight copy-everything step added. There's nothing I see there that would cause a previously thread-safe library to no longer be thread safe.
>There seems to be a severe lack of familiarity in the Perl community with what "real" threads are wrt "multithreading". No doubt this is not lost of many, but I continue to see over and over again the suggestion that Perl ithreads are related to traditional shared memory threads. This is simply not the case.
Lack of familiarity with the concept of "threads" or lack of familiarity with a particular implementation of "threads"? The concept of threads is easy, but threads are hard to use for everyone, unless someone has already abstracted it away for them.
| [reply] |
