3 ms·
With native threads, all your threads have their own identity and they're known to the OS task scheduler. So they can all block or run independently. But with g
by mahmud 17y ago
With native threads, all your threads have their own identity and they're known to the OS task scheduler. So they can all block or run independently. But with green threads, the OS doesn't know about your "threads"; when the parent process is blocked, so are all the threads.
- stonemetal 17y agoNote GP said multiprocessing (that is a python library for multiple processes with a thread like interface, not green threads.) As for why some see it as not enough well it is kind of like CGI vs FCGI spining up a whole new process with and VM is not a cheap operation compared to starting up a thread. Sure you can work around it with design changes pools and what not, but some would rather see the problem fixed correctly rather than worked around.
- barrkel 17y agoOne of the basic assumptions behind green threads is that you aren't going to make blocking OS calls from your green threads - the interpreter should intercept those, run them in a different thread (or ideally, run with async I/O) so that it can schedule a different thread until the call returns.
- zweiterlinde 17y agoIn the long run, it seems like approaches like ConCRT and User Mode Scheduling (Windows only, sadly) could address this. The OS can provide support for detecting any blocking operations (even page faults, for example) and doing task-level switching for you.