3 ms·

So writing to the main thread from a parallel context crashes the thread, but what about interrupting a parallel thread from the main thread and send data to it

by wyuenho 12y ago

So writing to the main thread from a parallel context crashes the thread, but what about interrupting a parallel thread from the main thread and send data to it? Not that one should do something like that but how does PyParallel handle it? Also, what would PyParallel look like if it has to support all these NIX systems? As the OP pointed out, all we do now for "async IO" on these NIX is basically polling the crap out of the OS.

trentnelson 12y ago
> So writing to the main thread from a parallel context crashes the thread Well... er, that's a bit of a vague sentence :-) > but what about interrupting a parallel thread from the main thread and send data to it? That is the most UNIX-ey signal-ly thing I've ever heard :-) That's sort of what's wrong with signals on UNIX, a paradigm that's useful at the process level when you have one thread of execution, but falls apart in a multithreading world. The correct approach is to use a mechanism like IOCP: https://speakerdeck.com/trent/pyparallel-how-we-removed-the-gil-and-exploited-all-cores?slide=63 https://speakerdeck.com/trent/pyparallel-how-we-removed-the-... That slide depicts how the kernel pushes completion packets onto an I/O completion port, such that they can be processed by waiting threads, but that's just one example. Anything can push a completion packet to an IOCP -- in fact, that's exactly how you'd get your parallel worker threads to gracefully shutdown: have the main thread enqueue a "shutdown please" completion packet (via PostQueuedCompletionStatus()), which you'd detect in your parallel threads. > Also, what would PyParallel look like if it has to support all these NIX systems? The GIL-sidestepping techniques via Py_PXCTX are conceptually platform independent -- they'll work fine on any POSIX platform (although things like interlocked lists that I get for free on Windows and OS X will need to be re-implemented on other platforms). The intrinsic pairing between asynchronous I/O and parallelism (that is, automatically and efficiently handling work in an I/O-driven system on all hardware cores) needs kernel-level support: https://speakerdeck.com/trent/parallelism-and-concurrency-with-python?slide=27 https://speakerdeck.com/trent/parallelism-and-concurrency-wi... Linux and BSD are the odd ones out here. AIX copied the IOCP API verbatim soon after NT 4.0 came out (I suspect they recognized a good thing when they saw it!), Solaris implemented something very close with event ports (except for the kernel being cognizant of event port concurrency, which is a key piece), and OS X got Grand Central Dispatch, which is a wildly different API (and a bit nicer, to be honest), but semantically equivalent to IOCP+threadpools on Windows. There are two outcomes re: Linux/BSD/POSIX support. 1. They implement the same kernel-level primitives for async I/O and synchronization supported by Windows/OSX, which PyParallel would be able to use directly. 2. They don't, so the PyParallel-backend is implemented via existing primitives (epoll/kqueue etc). I'm of the opinion that the Windows kernel-level primitives are fundamentally superior at the architectural level compared to the existing facilities provided by Linux/BSD/POSIX, evidenced by: a) better performance on identical hardware, b) less code required to achieve the desired effect, and c) much cleaner code versus the alternative.

by wyuenho 12y ago

trentnelson 12y ago

> So writing to the main thread from a parallel context crashes the thread Well... er, that's a bit of a vague sentence :-) > but what about interrupting a parallel thread from the main thread and send data to it? That is the most UNIX-ey signal-ly thing I've ever heard :-) That's sort of what's wrong with signals on UNIX, a paradigm that's useful at the process level when you have one thread of execution, but falls apart in a multithreading world. The correct approach is to use a mechanism like IOCP: https://speakerdeck.com/trent/pyparallel-how-we-removed-the-gil-and-exploited-all-cores?slide=63 https://speakerdeck.com/trent/pyparallel-how-we-removed-the-... That slide depicts how the kernel pushes completion packets onto an I/O completion port, such that they can be processed by waiting threads, but that's just one example. Anything can push a completion packet to an IOCP -- in fact, that's exactly how you'd get your parallel worker threads to gracefully shutdown: have the main thread enqueue a "shutdown please" completion packet (via PostQueuedCompletionStatus()), which you'd detect in your parallel threads. > Also, what would PyParallel look like if it has to support all these NIX systems? The GIL-sidestepping techniques via Py_PXCTX are conceptually platform independent -- they'll work fine on any POSIX platform (although things like interlocked lists that I get for free on Windows and OS X will need to be re-implemented on other platforms). The intrinsic pairing between asynchronous I/O and parallelism (that is, automatically and efficiently handling work in an I/O-driven system on all hardware cores) needs kernel-level support: https://speakerdeck.com/trent/parallelism-and-concurrency-with-python?slide=27 https://speakerdeck.com/trent/parallelism-and-concurrency-wi... Linux and BSD are the odd ones out here. AIX copied the IOCP API verbatim soon after NT 4.0 came out (I suspect they recognized a good thing when they saw it!), Solaris implemented something very close with event ports (except for the kernel being cognizant of event port concurrency, which is a key piece), and OS X got Grand Central Dispatch, which is a wildly different API (and a bit nicer, to be honest), but semantically equivalent to IOCP+threadpools on Windows. There are two outcomes re: Linux/BSD/POSIX support. 1. They implement the same kernel-level primitives for async I/O and synchronization supported by Windows/OSX, which PyParallel would be able to use directly. 2. They don't, so the PyParallel-backend is implemented via existing primitives (epoll/kqueue etc). I'm of the opinion that the Windows kernel-level primitives are fundamentally superior at the architectural level compared to the existing facilities provided by Linux/BSD/POSIX, evidenced by: a) better performance on identical hardware, b) less code required to achieve the desired effect, and c) much cleaner code versus the alternative.