>>>>> "Guido" == Guido van Rossum <guido at cnri.reston.va.us> writes:
Guido> It's also dangerous -- e.g. unexpected errors may percolate
Guido> down the wrong stack (many mailman bugs had to do with
Guido> forking), GUI apps generally won't be cloned, and some
Guido> extension libraries don't like to be cloned either
Guido> (e.g. ILU).
Rambling mode on...
Okay, so you can't guarantee that fork will be everywhere you might
want to run an application. For example, that's one of the main
reasons Mailman hasn't been ported off of Un*x. But you also can't
guarantee that threads will be everywhere either. One of the things
I'd (eventually) like to do is to re-architect Mailman so that it uses
a threaded central server instead of the current one-shot process
model. But there's been debate among the developers because 1)
threads aren't supported everywhere, and 2) thread support isn't
built-in by default anyway.
I wonder if it's feasible or useful to promote threading support in
Python? Thoughts would include building threads in by default if
possible on the platform, integrating Greg's free threading mods,
etc. Providing more integrated support for threads might encourage
programmers to reach for that particular tool instead of fork, which
is crude, but pretty damn handy and easy to use.
Rambling mode off...
-Barry
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4