PC loser-ing is a brilliant thing which also finds its use in various proofs about programming languages.
I guess the primary problem is that you have code out there which doesn't assume the presence of a signal handler in the code, yet suddenly you get EINTR back because of signal delivery in other libraries. Correctly programming Unix systems requires attention to detail :) On Wed, Feb 26, 2020 at 6:33 PM Amnon Baron Cohen <amno...@gmail.com> wrote: > from https://www.jwz.org/doc/worse-is-better.html > > Two famous people, one from MIT and another from Berkeley (but working on > Unix) once met to discuss operating system issues. The person from MIT was > knowledgeable about ITS (the MIT AI Lab operating system) and had been > reading the Unix sources. He was interested in how Unix solved the PC > loser-ing problem. > > The PC loser-ing problem occurs when a user program invokes a system > routine to perform a lengthy operation that might have significant state, > such as IO buffers. If an interrupt occurs during the operation, the state > of the user program must be saved. Because the invocation of the system > routine is usually a single instruction, the PC of the user program does > not adequately capture the state of the process. The system routine must > either back out or press forward. The right thing is to back out and > restore the user program PC to the instruction that invoked the system > routine so that resumption of the user program after the interrupt, for > example, re-enters the system routine. It is called ``PC loser-ing'' > because the PC is being coerced into ``loser mode,'' where ``loser'' is the > affectionate name for ``user'' at MIT. > > > The MIT guy did not see any code that handled this case and asked the New > Jersey guy how the problem was handled. The New Jersey guy said that the > Unix folks were aware of the problem, but the solution was for the system > routine to always finish, but sometimes an error code would be returned > that signaled that the system routine had failed to complete its action. A > correct user program, then, had to check the error code to determine > whether to simply try the system routine again. The MIT guy did not like > this solution because it was not the right thing. > > > The New Jersey guy said that the Unix solution was right because the > design philosophy of Unix was simplicity and that the right thing was too > complex. Besides, programmers could easily insert this extra test and loop. > The MIT guy pointed out that the implementation was simple but the > interface to the functionality was complex. The New Jersey guy said that > the right tradeoff has been selected in Unix-namely, implementation > simplicity was more important than interface simplicity. > > > On Wednesday, 26 February 2020 17:10:48 UTC, Manlio Perillo wrote: >> >> On Wednesday, February 26, 2020 at 4:14:38 PM UTC+1, Ian Lance Taylor >> wrote: >>> >>> On Wed, Feb 26, 2020 at 7:11 AM Manlio Perillo <manlio...@gmail.com> >>> wrote: >>> > >>> > On Wednesday, February 26, 2020 at 3:51:54 PM UTC+1, Peter Kleiweg >>> wrote: >>> >> >>> >> Op woensdag 26 februari 2020 13:05:40 UTC+1 schreef Manlio Perillo: >>> >>> >>> >>> On Wednesday, February 26, 2020 at 12:33:05 PM UTC+1, Peter Kleiweg >>> wrote: >>> >>>> >>> >>>> With Go version 1.14 I get a lot of errors when I run: >>> >>>> >>> >>>> go test -v github.com/pebbe/zmq4 >>> >>>> >>> >>>> I didn't see this with Go 1.13.8 or any earlier version. >>> >>>> >>> >>>> Is this a problem with Go 1.14, or am I doing something wrong and >>> just got lucky until now? >>> >>>> >>> >>>> How do I debug this? The errors are different for each run. Below >>> is a sample of some errors. >>> >>>> Line numbers are not always accurate, because I inserted some calls >>> to test.Log(). >>> >>> >>> >>> >>> >>> The errors are probably caused by >>> https://golang.org/doc/go1.14#runtime. >>> >>> >>> >>> The solution is to update zmq4 to explicitly handle interrupted >>> system calls. >>> >> >>> >> >>> >> Often the program freezes before I get an interrupted system call. It >>> hangs inside a ZeroMQ C++ library function. >>> >> zmq4 is just a wrapper for ZeroMQ. I can't "fix" ZeroMQ to make it >>> work with Go. >>> >> >>> >> Is there a way to stop Go from interrupting my system calls? It >>> happens rather randomly all over the place. >>> > >>> > >>> > >>> https://stackoverflow.com/questions/36040547/zeromq-how-to-react-on-different-signal-types-on-eintr >>> > >>> > ZeroMQ may return an EINTR error , but zmq4 does not list it in >>> errors.go. >>> > ZeroMQ asks the caller to handle EINTR, so zmq4 should handle it >>> internally or return it to the caller. >>> > >>> > https://golang.org/doc/go1.14#runtime should have mentioned that not >>> only programs that use packages like syscall or golang.org/x/sys/unix >>> will see more slow system calls fail with EINTR errors, but also programs >>> that use Cgo. >>> >>> I don't know ZeroMQ. If the ZeroMQ calls correspond closely to system >>> calls, then it could work for them to return EINTR. In that case the >>> fix is going to be for the Go wrapper around ZeroMQ to check whether >>> the error returned is syscall.EINTR, and to retry the call if it is. >>> >>> >> Unfortunately it is not that simple: >> >> http://250bpm.com/blog:12 >> https://alobbs.com/post/54503240599/close-and-eintr >> http://man7.org/linux/man-pages/man7/signal.7.html >> https://github.com/golang/go/issues/11180 >> https://www.python.org/dev/peps/pep-0475/ >> >> The second entry about close and EINTR is enlightening. >> >> >> Manlio >> > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/4b2677b3-ae0e-486f-802b-d3eb24bfc65f%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/4b2677b3-ae0e-486f-802b-d3eb24bfc65f%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- J. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAGrdgiUcN%3DOsURBXnrrCm4sn0jO9Cwmv0Hk%2BgAgUHffgHSJaRw%40mail.gmail.com.
