GODEBUG=noasyncpreempt=1 makes no difference.

I added the option -race and I got some warnings from that, all happening 
in a call to reactor.Run().
When I disable all tests that use reactor.Run() the test run no longer 
freezes. So I have to look at
the implementation of the reactor. 

I still get the interrupted system calls, so I have to fix those too.

It looks like these are two different issues.


Op donderdag 27 februari 2020 19:07:54 UTC+1 schreef Robert Engels:
>
> Does it freeze if you use GODEBUG=noasyncpreempt=1 ?
>
> -----Original Message----- 
> From: Peter Kleiweg 
> Sent: Feb 27, 2020 11:59 AM 
> To: golang-nuts 
> Subject: Re: [go-nuts] Re: Lot's of test errors in package zmq4 with Go 
> version 1.14, no errors with earlier versions 
>
> 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> 
>> 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 golan...@googlegroups.com <javascript:>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/a76d2e26-2ed9-4f7a-beee-c95244743e2e%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/golang-nuts/a76d2e26-2ed9-4f7a-beee-c95244743e2e%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
>
>
>
>

-- 
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/a95feca4-17f4-4a43-80c7-3adc76d0cabf%40googlegroups.com.

Reply via email to