S
Steven Simpson
What class is this? Is it specified somewhere?
Cheers!
What class is this? Is it specified somewhere?
Cheers!
J
Jan Burse
Arne said:
Its simply broken because of the following
chain of reasoning.
- InputStream/OutputStream are supposed
to be blocking IO in contrast to NIO.
- When a shutdown sequence is initiated
no InputStream/OutputStream is killed
they remain blocking in case they were
already blocking.
so that the shutdown hooks can gracefully
terminate their service. For example
a goodbye sequence with a web server, etc..
- SIGINT when available, by default
initiates a shutdown sequence.
- The Windows behaviour for CONIN$ violates
the above, since during SIGINT the
CONIN$ becomes non-blocking in that
it returns EOF.
So this is what is broken here. It contaminates
any sensible use of shutdown hooks as described
here in the case of Windows:
http://docs.oracle.com/javase/1.4.2...untime.html#addShutdownHook(java.lang.Thread)
Best Regards
S
Silvio Bierman
I suppose I am not the original out-of-the-box thinking mind you are.
Some empathy on your side would have been nice.
J
Jan Burse
Steven said:
Its a custom made wrapper for Signal & SignalHandler.
In version 1 of the above class I used the package
sun.misc.*. In version 2 of the above class I
used reflection i.e. Proxy class etc.. It will
noop when sun.misc.Signal is not present.
See for example:
http://stackoverflow.com/questions/2783595/dynamic-reflective-signalhandler-in-java
It is not portable, since sun.misc.* is not official
part of the JDK. But testing showed that the reflection
stuff works fine for the cases when sun.misc.* is
present.
The reflection thing is also useful when the code by
chance lands in an applet. Some verifier murne the use
of sun.misc.* inside an applet, even if during the
execution of the applet the package is not called.
There is some post on the web where Oracle/Sun claims
they never said they WILL remove sun.misc.*, they only
said they MIGHT remove sun.misc.*.
Best Regards
J
Jan Burse
Jan said:
Especially a couple of headless scenarios.
Bye
J
Jan Burse
Patricia said:
Hi,
Using a loosely coupled solution (i.e. two processes or
so) is only second priority. First priority is a fully
integrated solution. Something along:
public class FileInputStreamFix extends FileInputStream;
I alreay tried subclassing FileInputStream. Works fine.
For example I experimented with a
public class FileInputStreamTest1 extends FileInputStream {
public void close() throws IOException {
/* do nothing */
}
}
By the above you get a file input stream that cannot be
closed. I noticed that some JNA solutions bundle a DLL
inside the resources of the application. At runtime they
then unpack/download this resource to a local location
and invoke loadLibrary().
So I guess a fully integrated solution should be possible
that carries its own Windows specific code.
Best Regards
J
Jan Burse
Joshua said:
Since the whole application works fine on Linux and Mac,
and it is entirely written with Java, I am quite happy
with Java. It is only that there is a small obstacle with
Windows.
I am quite astonished that from such a small obstacle you
more or less suggest suicide. I guess you lack perseverance
and discipline.
Bye
A
Arne Vajhøj
It is common for almost the definition of non portable code
that it works on some platforms and not on other.
It is you that lack discipline.
Joshua would have had implemented one of the proposed
solutions by know and moved on to next problem.
You are still stuck in the swamp you have invented.
Arne
A
Arne Vajhøj
Well that doc does not state anything about streams remain blocked.
It is just something you have invented.
You may still consider that "sensible use", but the fact
remains that:
* nothing in Java is broken
* your code is broken
because the behavior is not specified.
You can not design your programs after how you think
the platform should behave - you have to code after
how it actually behave.
And that includes staying away from something that
is not well defined.
Arne
A
Arne Vajhøj
Joshua has rather precise outlined your possibilities.
You need to make a choice an move forward.
Arne
A
Arne Vajhøj
They might.
And it may not be present in Java implementations from
other than SUN/Oracle.
It is a rather risky business to rely on such
features.
Arne
J
Jan Burse
Arne said:
I was faster, I implemented already Gabriel Genellina
solution (see Link in my very first post) a couple
of days ago.
But maybe Joshua could share his solution, so that
we could compare notes.
Bye
J
Jan Burse
Arne said:
How does Joshua then do it?
Bye
J
Jan Burse
Arne said:
InputStream/OutputStream are blocking I/O
for the standard I/O resources delivered
by the standard library.
Although the API would allow very fine non-
blocking, for example via throwing Interrupted-
IOException, but most of the piggy pack readers/
writes don't support it properly.
NIO is non-blocking in some circumstance.
Do you need proof?
http://www.ibm.com/developerworks/java/library/j-javaio/
How much do you know about Java?
Bye
J
Jan Burse
Jan said:
Again a sign that this Java is a *frigging
cheap RI* implementation.
Bye
A
Arne Vajhøj
All his suggestions were for using well defined
and supported behavior.
Arne
A
Arne Vajhøj
Yes.
But that does not guarantee that they will not return
in case of various control characters like CTRL/C on
certain platforms.
Yes, please.
That articles does not say anything about what happens
if interrupted by CTRL/C or similar.
Arne
A
Arne Vajhøj
You first post was a question not a solution.
And you have already admitted that the code uses
sun.* classes so it is not reliable.
Share what?
Arne
J
Jan Burse
Sorry its a solution by "Maxim Khitrov". So how does
the solution look like in Java?
I did some measurement with System.nanoTime(), which
is only available since JDK 1.5. It showed the
following:
There is in the average a delay of ~1 (ms)
between that readLine() returns EOF and
that the SIGINT handler is invoked.
So I opted for a Gabriel Genellina solution with a
threshold of EOF_SLEEP = 10 (ms). The code reads
as follows:
for(;
{
String line = br.readLine();
INThappened = false;
if (line != null) {
return line;
} else {
long when = System.currentTimeMillis() + EOF_SLEEP;
long sleep = EOF_SLEEP;
while (sleep > 0) {
Thread.sleep(sleep);
sleep = when - System.currentTimeMillis();
}
if (!INThappened) {
return null;
}
}
}
I don't particularly like the solution, since
it might give false negatives. For example if
there is a really an EOF and in the same time
a SIGINT, the EOF might be suppressed.
The SIGINT handler is supposed to do as it
first statement:
INThappened = true;
I did the time measurement with Windows 7 / JDK
1.7 / Sony VAIO VPC-SA3J1E/XI. Maybe another
hardware / software might yield a different
estimate of the average delay. Also the delay
might depend on the system load.
So eventually EOF_SLEEP would need adjustment.
But it is below the 50ms that Maxim Khitrov
suggested:
http://www.gossamer-threads.com/lists/python/python/781893
But eventually should use ReentrantLock and
Condition with awaitNano() from java.concurrent,
since the Thread.sleep might anyway not deliver
the fine grained 10ms.
Bye
the solution look like in Java?
I did some measurement with System.nanoTime(), which
is only available since JDK 1.5. It showed the
following:
There is in the average a delay of ~1 (ms)
between that readLine() returns EOF and
that the SIGINT handler is invoked.
So I opted for a Gabriel Genellina solution with a
threshold of EOF_SLEEP = 10 (ms). The code reads
as follows:
for(;
{String line = br.readLine();
INThappened = false;
if (line != null) {
return line;
} else {
long when = System.currentTimeMillis() + EOF_SLEEP;
long sleep = EOF_SLEEP;
while (sleep > 0) {
Thread.sleep(sleep);
sleep = when - System.currentTimeMillis();
}
if (!INThappened) {
return null;
}
}
}
I don't particularly like the solution, since
it might give false negatives. For example if
there is a really an EOF and in the same time
a SIGINT, the EOF might be suppressed.
The SIGINT handler is supposed to do as it
first statement:
INThappened = true;
I did the time measurement with Windows 7 / JDK
1.7 / Sony VAIO VPC-SA3J1E/XI. Maybe another
hardware / software might yield a different
estimate of the average delay. Also the delay
might depend on the system load.
So eventually EOF_SLEEP would need adjustment.
But it is below the 50ms that Maxim Khitrov
suggested:
http://www.gossamer-threads.com/lists/python/python/781893
But eventually should use ReentrantLock and
Condition with awaitNano() from java.concurrent,
since the Thread.sleep might anyway not deliver
the fine grained 10ms.
Bye
J
Jan Burse
Jan said:
Corr:
So I opted for a "Maxim Khitrov" solution with a