Gerhard Fiedler wrote: > Carl J. Van Arsdall wrote: > > Well, I guess I'm thinking of an event driven mechanism, kinda like > > setting up signal handlers. I don't necessarily know how it works under > > the hood, but I don't poll for a signal. I setup a handler, when the > > signal comes, if it comes, the handler gets thrown into action. That's > > what I'd be interesting in doing with threads. > > What you call an event handler is a routine that gets called from a message > queue polling routine. You said a few times that you don't want that.
I think he's refering to Unix signal handlers. These really are called asynchronously. When the signal comes in, the system pushes some registers on the stack, calls the signal handler, and when the signal handler returns it pops the registers off the stack and resumes execution where it left off, more or less. If the signal comes while the process is in certain system calls, the call returns with a value or errno setting that indicated it was interrupted by a signal. Unix signals are an awkward low-level relic. They used to be the only way to do non-blocking but non-polling I/O, but current systems offer much better ways. Today the sensible things to do upon receiving a signal are ignore it or terminate the process. My opinion, obviously. -- --Bryan -- http://mail.python.org/mailman/listinfo/python-list
