Russell Owen <ro...@uw.edu>: > I think what I'm looking for is a task-like thing I can create that I > can end when *I* say it's time to end, and if I'm not quick enough > then it will time out gracefully. But maybe there's a simpler way to > do this. It doesn't seem like it should be difficult, but I'm stumped. > Any advice would be appreciated.
I have experimented with similar questions in the past. FWIW, you can see my small program here: <URL: http://pacujo.net/~marko/philosophers.py> Occasionally, people post questions here about asyncio, but there are few answers. I believe the reason is that asyncio hasn't broken through as a very popular programming model even with Python enthusiasts. I do a lot of network and system programming where event multiplexing is essential. There are different paradigms to manage concurrency and parallelism: * multithreading * multiprocessing * coroutines * callbacks from an event loop Out of these, I prefer callbacks and processes and steer clear of threads and coroutines. The reason is that in my (long) experience, Callbacks and processes make simple problems hard but manageable. Callbacks and processes make complex problems hard but manageable. Threads and coroutines make simple problems simple to solve. Threads and coroutines make complex problems humanly intractable. Why is this? Threads and coroutines follow the same line of thinking. They assume that concurrency involves a number linear state machines ("threads") that operate independently from each other. The "linear" part means that in each blocking state, the thread is waiting for one very definite event. When there are a number of possible events in each state -- which there invariably are -- the multithreading model loses its attractiveness. Marko -- https://mail.python.org/mailman/listinfo/python-list