Path: csiph.com!usenet.pasdenom.info!gegeweb.org!newsfeed.kamp.net!newsfeed0.kamp.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Robert Klemme <shortcutter@googlemail.com>
Newsgroups: comp.lang.java.programmer
Subject: Re: [Windows] Any way to distinguish ^C Induced EOF from ^Z EOF?
Date: Mon, 12 Mar 2012 23:02:41 +0100
Lines: 37
Message-ID: <9s7a41F4a9U1@mid.individual.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>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Trace: individual.net FiirzpKQU1WKXzc2VTo9NAXJYh4RvC9K7Q5u941eVGtqnVs0g=
Cancel-Lock: sha1:ntIy1qjkikxDedUyuTJAEbZidSk=
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
In-Reply-To: <jjlqdt$uln$1@news.albasani.net>
Xref: csiph.com comp.lang.java.programmer:12924

On 03/12/2012 10:39 PM, Jan Burse wrote:
> Arne Vajh=F8j schrieb:
>> No but you ask users to enter it and complain
>> about its behavior.
>
> No, I only gave an example. The example does also
> go wrong on the Windows platform when you use (I
> tested it):
>
> cygwin
>
> And for example issue a kill from another process.
> Its deeply rooted in the behaviour of CON respectively
> CONIN$. And it is even documented by MS.

What do you expect then?  A signal handler is concurrent by design.  If=20
the OS implementors chose to also automatically EOF the console the two=20
cannot know from each other without introducing synchronization overhead =

just for this single case.  I doubt for any serious JVM implementor=20
would trade off in this direction.

Plus, since there is concurrency involved there is not much guarantees=20
cross platform anyway.  I also agree to Arne's position that it is=20
unwise to commit on EOF and rollback otherwise: the more robust code is=20
always to commit only when explicitly advised and rollback in all other=20
cases.  Because only with explicit advice to commit you know the code=20
behaved as intended.  But if a program crashes or dies otherwise (OOM=20
for example) you cannot know whether all intended changes were applied.

So yes, the example is quite artificial (you also called it "naive"=20
IIRC).  But what follows from bad code?

Cheers

	robert