Path: csiph.com!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail
From: Jan Burse <janburse@fastmail.fm>
Newsgroups: comp.lang.java.programmer
Subject: Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF?
Date: Tue, 13 Mar 2012 00:18:34 +0100
Organization: albasani.net
Lines: 30
Message-ID: <jjm08a$a9f$1@news.albasani.net>
References: <jjj3ke$jev$1@news.albasani.net> <4f5d18ef$0$291$14726298@news.sunsite.dk> <jjj6m3$qep$1@news.albasani.net> <4f5d239d$0$293$14726298@news.sunsite.dk> <jjj8ll$v36$1@news.albasani.net> <jjja9e$f43$1@dont-email.me> <jjkhbj$tuq$1@news.albasani.net> <4f5e3743$0$293$14726298@news.sunsite.dk> <jjli1s$ac7$1@news.albasani.net> <4f5e5780$0$282$14726298@news.sunsite.dk> <jjlm7u$kin$1@news.albasani.net> <4f5e61f3$0$281$14726298@news.sunsite.dk> <jjlqdt$uln$1@news.albasani.net> <9s7a41F4a9U1@mid.individual.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.albasani.net 4KWu4IIlhQkPfoFbPZUL95cW2diPtU4uvTcpiIYbBlnIFfZUA+9MRmrdsO6tiYEXyIl9vX0IIf8gKXNQFqvxhDosYE7vQksux56Cnl0E1me9jrtEuJm7mDsBhw1pWEOp
NNTP-Posting-Date: Mon, 12 Mar 2012 23:18:34 +0000 (UTC)
Injection-Info: news.albasani.net; logging-data="ICIg3hxZoX7adawO7q4tFg6o5lTxP0KXTXmFcp04rgscEH1Pkd3cGZZf8ZvBNCNilg8BxrRWXoYmf84M/14v4aXNg60l/IMEfueN2saDaZZKIVB7huEWAz79BZNO5J6+"; mail-complaints-to="abuse@albasani.net"
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Firefox/10.0.2 SeaMonkey/2.7.2
In-Reply-To: <9s7a41F4a9U1@mid.individual.net>
Cancel-Lock: sha1:TXc7rHernVXoaxpKVPTkLSY1l5c=
Xref: csiph.com comp.lang.java.programmer:12928

Robert Klemme schrieb:
> each other without introducing synchronization overhead just for this
> single case.  I doubt for any serious JVM implementor would trade off in
> this direction.

Thats a good point. It could be that the following hack
is not thread safe:

http://www.mail-archive.com/chicken-hackers@nongnu.org/msg01846.html

But may something could be done with for a readBytes() returning
len = 0 versus len = -1.

The upper layers BufferedReader etc.. anyway introduce their own
locks, and they can do the re-read when len = 0.

But this is also most often blured, there are different implementations
among the different JDKs, some are not able to do the re-read and
other ares.

My only requirement would be that allternating Threads can use
BufferedReader readLine and the len = 0 does not confuse these
readLines, i.e. add additional empty lines.

I think the later requirement is easily archiveable.

Bye