https://github.com/golang/go/issues/36281
https://github.com/pebbe/zmq4/issues/17
On Wednesday, February 26, 2020 at 3:33:05 AM UTC-8, 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
On Fri, Feb 28, 2020 at 9:39 AM Manlio Perillo wrote:
>
> On Friday, February 28, 2020 at 6:29:56 PM UTC+1, Ian Lance Taylor wrote:
>>
>> On Fri, Feb 28, 2020 at 9:14 AM Manlio Perillo wrote:
>> >
>> > On Friday, February 28, 2020 at 5:36:09 PM UTC+1, Ian Lance Taylor wrote:
>> >>
>> >> On Fri,
On Friday, February 28, 2020 at 6:29:56 PM UTC+1, Ian Lance Taylor wrote:
>
> On Fri, Feb 28, 2020 at 9:14 AM Manlio Perillo > wrote:
> >
> > On Friday, February 28, 2020 at 5:36:09 PM UTC+1, Ian Lance Taylor
> wrote:
> >>
> >> On Fri, Feb 28, 2020 at 8:27 AM Manlio Perillo
> wrote:
> >>
On Fri, Feb 28, 2020 at 9:14 AM Manlio Perillo wrote:
>
> On Friday, February 28, 2020 at 5:36:09 PM UTC+1, Ian Lance Taylor wrote:
>>
>> On Fri, Feb 28, 2020 at 8:27 AM Manlio Perillo wrote:
>> >
>> > On Friday, February 28, 2020 at 4:57:00 PM UTC+1, Ian Lance Taylor wrote:
>> >>
>> >> On Fri,
On Friday, February 28, 2020 at 5:36:09 PM UTC+1, Ian Lance Taylor wrote:
>
> On Fri, Feb 28, 2020 at 8:27 AM Manlio Perillo > wrote:
> >
> > On Friday, February 28, 2020 at 4:57:00 PM UTC+1, Ian Lance Taylor
> wrote:
> >>
> >> On Fri, Feb 28, 2020 at 7:18 AM Peter Kleiweg
> wrote:
> >> >
On Fri, Feb 28, 2020 at 8:13 AM Peter Kleiweg wrote:
>
> Op vrijdag 28 februari 2020 16:57:00 UTC+1 schreef Ian Lance Taylor:
>>
>> On Fri, Feb 28, 2020 at 7:18 AM Peter Kleiweg wrote:
>> >
>> > Op vrijdag 28 februari 2020 16:13:50 UTC+1 schreef Robert Engels:
>> >>
>> >>
>> >> Can you clarify
On Fri, Feb 28, 2020 at 8:27 AM Manlio Perillo wrote:
>
> On Friday, February 28, 2020 at 4:57:00 PM UTC+1, Ian Lance Taylor wrote:
>>
>> On Fri, Feb 28, 2020 at 7:18 AM Peter Kleiweg wrote:
>> >
>> > Op vrijdag 28 februari 2020 16:13:50 UTC+1 schreef Robert Engels:
>> >>
>> >>
>> >> Can you
On Friday, February 28, 2020 at 4:57:00 PM UTC+1, Ian Lance Taylor wrote:
>
> On Fri, Feb 28, 2020 at 7:18 AM Peter Kleiweg > wrote:
> >
> > Op vrijdag 28 februari 2020 16:13:50 UTC+1 schreef Robert Engels:
> >>
> >>
> >> Can you clarify that a bit? Did you change the code to look for EINTR
Op vrijdag 28 februari 2020 16:57:00 UTC+1 schreef Ian Lance Taylor:
>
> On Fri, Feb 28, 2020 at 7:18 AM Peter Kleiweg > wrote:
> >
> > Op vrijdag 28 februari 2020 16:13:50 UTC+1 schreef Robert Engels:
> >>
> >>
> >> Can you clarify that a bit? Did you change the code to look for EINTR
>
On Fri, Feb 28, 2020 at 7:18 AM Peter Kleiweg wrote:
>
> Op vrijdag 28 februari 2020 16:13:50 UTC+1 schreef Robert Engels:
>>
>>
>> Can you clarify that a bit? Did you change the code to look for EINTR errors
>> and then retry the system call?
>
>
> Yes, I did. But as an option that must be
Op vrijdag 28 februari 2020 16:13:50 UTC+1 schreef Robert Engels:
>
>
> Can you clarify that a bit? Did you change the code to look for EINTR
> errors and then retry the system call?
>
Yes, I did. But as an option that must be enabled by the user.
> -Original Message-
> From: Peter
Can you clarify that a bit? Did you change the code to look for EINTR errors and then retry the system call?-Original Message-
From: Peter Kleiweg
Sent: Feb 28, 2020 9:04 AM
To: golang-nuts
Subject: [go-nuts] Re: Lot's of test errors in package zmq4 with Go version 1.14, no errors with
Retry after EINTR solved the code lock-up too.
Op woensdag 26 februari 2020 12:33:05 UTC+1 schreef Peter Kleiweg:
>
> 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
As Ian pointed out you need to use
GODEBUG=asyncpreemptoff=1
> On Feb 27, 2020, at 2:26 PM, Peter Kleiweg wrote:
>
>
> 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
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
On Thu, Feb 27, 2020 at 10:07 AM Robert Engels wrote:
>
> Does it freeze if you use GODEBUG=noasyncpreempt=1 ?
Sorry, I got it wrong earlier. It's GODEBUG=asyncpreemptoff=1.
I can verify that the tests seem to pass with
GODEBUG=asyncpreemptoff=1, and hang without it.
I took a quick look at
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
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 > 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
On Thu, Feb 27, 2020 at 9:41 AM Robert Engels 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
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
I think the difference is that a user program can block signals when working
with certain devices. With Go that is not possible so the only choice is to not
use Go.
Unless I am missing something else?
> On Feb 27, 2020, at 9:52 AM, Ian Lance Taylor wrote:
>
> On Wed, Feb 26, 2020 at 8:36
On Wed, Feb 26, 2020 at 8:36 PM Robert Engels wrote:
>
> The problem is that Go designers are taking the position that any sys call
> should be able to be interrupted. This is invalid. For the vast majority or
> “unix” os an interrupt is a very rare condition and so they treat it as an
>
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
On Thursday, February 27, 2020 at 2:15:14 AM UTC+1, Ian Lance Taylor wrote:
>
> On Wed, Feb 26, 2020 at 9:11 AM 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
> wrote:
Ian, I guess not. I’d not thought of that indirectness. I withdraw my
musings.
On Wed, Feb 26, 2020 at 8:36 PM Robert Engels wrote:
> The problem is that Go designers are taking the position that any sys call
> should be able to be interrupted. This is invalid. For the vast majority or
> “unix”
The problem is that Go designers are taking the position that any sys call
should be able to be interrupted. This is invalid. For the vast majority or
“unix” os an interrupt is a very rare condition and so they treat it as an
error. If you issue interrupts continually you are creating an
On Wed, Feb 26, 2020 at 5:51 PM Michael Jones wrote:
>
> Sorry...I meant the go system signal interface could loop if desired. (Not
> recommending, just saying that panicky people could be coddled if desired)
Ah, I see. Except, no, I don't. Could we really do that? Even if
the signal arrived
Sorry...I meant the go system signal interface could loop if desired. (Not
recommending, just saying that panicky people could be coddled if desired)
On Wed, Feb 26, 2020 at 5:48 PM Ian Lance Taylor wrote:
> On Wed, Feb 26, 2020 at 5:42 PM Michael Jones
> wrote:
> >
> > There is the BSD notion
On Wed, Feb 26, 2020 at 5:42 PM Michael Jones wrote:
>
> There is the BSD notion of sa_restart, a convenience to loop for the caller
> as appropriate.
>
> https://www.freebsd.org/cgi/man.cgi?query=sigaction
>
> Go could adopt such a notion if desired.
We already do. We install all signal
There is the BSD notion of sa_restart, a convenience to loop for the caller
as appropriate.
https://www.freebsd.org/cgi/man.cgi?query=sigaction
Go could adopt such a notion if desired.
On Wed, Feb 26, 2020 at 5:14 PM Ian Lance Taylor wrote:
> On Wed, Feb 26, 2020 at 9:11 AM Manlio Perillo
>
On Wed, Feb 26, 2020 at 9:11 AM 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 wrote:
>> >
>> > On Wednesday, February 26, 2020 at 3:51:54 PM UTC+1, Peter Kleiweg wrote:
>> >>
>> >> Op
How should I handle EINTR from syscall.Dup2 (Linux)?
- The effect of SA_RESTART on dup2(2) is undocumented.
- If dup2 returns EINTR, can I be sure that nothing has been done? (Otherwise
retrying is racy.)
- libuv uv__dup2_cloexec [1] never retries the syscall but treats EINTR as a
failure.
-
It is especially difficult when the driver has complex timing and/or hardware
flags. Interrupting these calls usually lead to unretriable failures.
> On Feb 26, 2020, at 11:41 AM, Peter Kleiweg wrote:
>
>
> That leaves the problem that often, the program just waits forever in C code,
> not
That leaves the problem that often, the program just waits forever in C
code, not returning an interrupted system call.
Op woensdag 26 februari 2020 16:14:38 UTC+1 schreef Ian Lance Taylor:
>
> On Wed, Feb 26, 2020 at 7:11 AM Manlio Perillo > wrote:
> >
> > On Wednesday, February 26, 2020 at
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
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 > 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
On Wed, Feb 26, 2020 at 7:11 AM Manlio Perillo 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:
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:
>>>
>>>
This looks like fallout of the 1.14 changes that made Goroutines
preemptively schedulable.
It seems likely that this code hasn't worked before either, just that
the failure cases were masked because less signals got delivered (and
thus had less chance of interrupting system calls).
On
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
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
This is with go version go1.14 linux/amd64
Op woensdag 26 februari 2020 12:33:05 UTC+1 schreef Peter Kleiweg:
>
> 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
42 matches
Mail list logo
