Op donderdag 27 februari 2020 18:50:56 UTC+1 schreef Ian Lance Taylor: > > On Thu, Feb 27, 2020 at 9:41 AM Robert Engels <ren...@ix.netcom.com > <javascript:>> wrote: > > > > > > I re-read your comments, and I agree that a rare error is still and > error, and needs to be handled, but if it the platform is introducing lots > of errors, is that the library writers issue? > > > > Maybe an easy solution is a flag to disable the signal usage for > tight-loop preemption as a "backwards compatibility" mode ? > > > > As the OP pointed out, he can't really change ZeroMQ, and this is a > fairly established product, maybe more so than Go, so doesn't it make more > sense that Go adapts rather than the other way around? > > We already have that flag: GODEBUG=noasyncpreempt=1. > > The discussion upthread explains that the Go wrapper for ZeroMQ should > handle EINTR, and take the appropriate action such as retrying the > operation when appropriate. The response to that was a bit of > distraction, as it discussed generic problems with EINTR. At this > point there is no reason to assume that any of those problems actually > apply to using ZeroMQ. >
Yes, a lot is said about handling EINTR. Nothing is said about the code just freezing. How to handle that? -- 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/a76d2e26-2ed9-4f7a-beee-c95244743e2e%40googlegroups.com.
