Le dimanche 31 août 2014, Marko Rauhamaa <ma...@pacujo.net> a écrit :
> Victor Stinner <victor.stin...@gmail.com <javascript:;>>: > > > Sorry but I don't understand your remark. What is your problem with > > retrying syscall on EINTR? > > The application will often want the EINTR return (exception) instead of > having the function resume on its own. This case is described as the use case #2 in the PEP, so it is supported. As written in the PEP, if you want to be notified of the signal, set a signal handler which raises an exception. For example the default signal handler for SIGINT raises KeyboardInterrupt. > > Can you please elaborate? What do you mean by "get wrong"? > > Proper handling of signals is difficult and at times even impossible. > For example it is impossible to wake up reliably from the select(2) > system call when a signal is generated (which is why linux now has > pselect). In my experience, using signal.set_wakeup_fd() works well with select(), even on Windows. The PEP promotes this. It is even thread safe. I don't know issues of signals with select() (and without a file descriptor used to wake up it). Python now exposes signal.pthread_sigmask(), I don't know if it helps. In my experience, signals don't play well with multithreading. On FreeBSD, the signal is send to a "random" thread. So you must have the same signal mask on all threads if you want to rely on them. But I don't get you point. How does this PEP make the situation worse? Victor
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com