On Oct 21, 4:58 am, sokol <[EMAIL PROTECTED]> wrote: > On Oct 21, 2:19 am, greg <[EMAIL PROTECTED]> wrote: > > > sokol wrote: > > > What was a surprise to me was that python sched.py makes the same > > > mistake as I did in my first version. > > > The sched module is *not* designed for multithreading. It > > assumes that the thread waiting for events is the only one > > putting events into the queue, so it's impossible for an > > event to get scheduled while in the midst of a sleep. It > > also doesn't take any measures to protect its data structures > > from concurrent access. > > > The documentation could make this clearer, especially since > > it confusingly talks about "allowing other threads to run". > > I find that hard to believe. Scheduler in single threaded > application is useless (well, you can correct me because > right now I can't come up with an example). Also, the > scheduler runs inside a loop. How do you suppose to > run other code while the loop is executing? Remember, all > you have is a single thread. The consequence of this is > that the only way to insert something new inside a queue > is by doing it from scheduled function.
Yeah, that does happen. I often used this sort of thing (pre-Python days, so a long time ago) in single-threaded, real-time simulations. Don't know mcuh about the sched module, but time scheduling in general doesn't need multithreading, not one bit. Carl Banks -- http://mail.python.org/mailman/listinfo/python-list
