View Problem Report: 12860
Audit Trail:
Responsible changed from "nobody" to "mflatt" by mflatt at racket-lang.org at Thu, 21 Jun 2012 22:06:44 -0400
Reason>>> A commit by mflatt at racket-lang.org has resolved this report
http://git.racket-lang.org/plt/commit/d253b89ba8
State changed from "open" to "closed" by mflatt at racket-lang.org at Thu, 21 Jun 2012 22:06:44 -0400
Reason>>> A commit by mflatt at racket-lang.org has resolved this report
http://git.racket-lang.org/plt/commit/d253b89ba8
From: Tony Garnock-Jones <tonyg at ccs.neu.edu>
To: tonyg at ccs.neu.edu, bugs at racket-lang.org, bug-notification at racket-lang.org,
mflatt at racket-lang.org
Cc:
Subject: Re: all/12860: Corrupted input in read-bytes-evt when using alarm-evt
too
Date: Fri, 22 Jun 2012 00:00:11 -0400
Thanks for that Matthew! That's working well for read-bytes-evt.
However, the same problem crops up if read-bytes!-evt is used instead of
read-bytes-evt, which is a bit weird.
I've put the test program, modified to use read-bytes!-evt (reusing the
same event and buffer each time around), up on github at
https://github.com/tonyg/racket-pr12860 - is there still a problem
remaining to be fixed, or have I done something silly in my code?
Regards, and thanks again,
Tony
From: Matthew Flatt <mflatt at cs.utah.edu>
To: Tony Garnock-Jones <tonyg at ccs.neu.edu>
Cc: "bugs at racket-lang.org" <bugs at racket-lang.org>,
"bug-notification at racket-lang.org" <bug-notification at racket-lang.org>,
"mflatt at racket-lang.org" <mflatt at racket-lang.org>
Subject: Re: all/12860: Corrupted input in read-bytes-evt when using alarm-evt too
Date: Fri, 22 Jun 2012 13:35:44 +0800
Hm, yes, I should have checked that. Inthis case, I think the docs may promise more than the implementation can deliver, but I'll look into it more.
On Jun 22, 2012, at 12:00 PM, Tony Garnock-Jones <tonyg at ccs.neu.edu> wrote:
> Thanks for that Matthew! That's working well for read-bytes-evt.
> However, the same problem crops up if read-bytes!-evt is used instead of
> read-bytes-evt, which is a bit weird.
>
> I've put the test program, modified to use read-bytes!-evt (reusing the
> same event and buffer each time around), up on github at
> https://github.com/tonyg/racket-pr12860 - is there still a problem
> remaining to be fixed, or have I done something silly in my code?
>
> Regards, and thanks again,
> Tony
>
From: Tony Garnock-Jones <tonyg at ccs.neu.edu>
To: Matthew Flatt <mflatt at cs.utah.edu>
Cc: "bugs at racket-lang.org" <bugs at racket-lang.org>,
"bug-notification at racket-lang.org" <bug-notification at racket-lang.org>,
"mflatt at racket-lang.org" <mflatt at racket-lang.org>
Subject: Re: all/12860: Corrupted input in read-bytes-evt when using alarm-evt
too
Date: Sat, 23 Jun 2012 08:01:26 -0400
On 2012-06-22 1:35 AM, Matthew Flatt wrote:
> Hm, yes, I should have checked that. Inthis case, I think the docs may promise more than the implementation can deliver, but I'll look into it more.
Thanks. Your fix for read-bytes-evt has let me continue with my work, so
this is much less urgent, to me at any rate :-)
Regarding read-bytes!-evt, though, I should point out I'm not doing any
concurrent synchronisation: all I'm doing is reusing a read-bytes!-evt
instance in a loop. Without the alarm event, everything works fine; with
the alarm event, the input is corrupted.
I don't mind the buffer being overwritten, er, optimistically during the
sync call, but I was surprised that the bytes were *consumed* (or
somehow reordered - I haven't quite gotten to the bottom of the nature
of the corruption itself) when the read-bytes!-evt was ready but not
selected.
Cheers,
Tony
From: Matthew Flatt <mflatt at cs.utah.edu>
To: Tony Garnock-Jones <tonyg at ccs.neu.edu>
Cc: "bugs at racket-lang.org" <bugs at racket-lang.org>,
"bug-notification at racket-lang.org" <bug-notification at racket-lang.org>
Subject: Re: all/12860: Corrupted input in read-bytes-evt when using alarm-evt
too
Date: Sun, 24 Jun 2012 07:33:59 -0600
At Sat, 23 Jun 2012 08:01:26 -0400, Tony Garnock-Jones wrote:
> Regarding read-bytes!-evt, though, I should point out I'm not doing any
> concurrent synchronisation: all I'm doing is reusing a read-bytes!-evt
> instance in a loop.
Yes, but the implementation of `read-bytes!-evt' requires a thread in
the background. A lack of any way to atomically cancel that thread when
another event is selected is essentially the problem that I have in
mind (and I think it's a deep, N-way-rendezvous kind of problem).
> I don't mind the buffer being overwritten, er, optimistically during the
> sync call, but I was surprised that the bytes were *consumed* (or
> somehow reordered - I haven't quite gotten to the bottom of the nature
> of the corruption itself) when the read-bytes!-evt was ready but not
> selected.
I will push a change the implementation and the guarantees of
`read-bytes!-evt' that weakens the guarantees but also makes your
example work.
----------
A commit by mflatt at racket-lang.org was marked as relevant
http://git.racket-lang.org/plt/commit/c11527494e
![[logo]](http://racket-lang.org/logo.png){kind=logo}