Windows, I/O is not interruptable.

[Nicholas Jordan]

Not even under the ... "New Technology" kernel or memphis ?

In windows.h, there are several calls that wait for object, then return if nothing is cooking (no data in io buffer). Are you saying the JVM does not cook the io till it runs full-tilt-boogie, or are you saying

It'll never happen

under winnie, no matter the build or os.



This is central to my testing strategy, and is a non-trivial inquiriy.
[added 12/24/2006 - much of what was originally posted here has an unstated heavy emphasis on time-intensive/reliability-critcal issues that I poorly guaged the responder's assessment of]

[ December 24, 2006: Message edited by: Nicholas Jordan ]
[ December 27, 2006: Message edited by: Nicholas Jordan ]

[Jim Yingst]

It's difficult to tell what you're talking about here, Nicholas. There seems to be some context which you're assuming we know about - we don't. Well, I don't.

[Nicholas]: Are you saying

Is who saying? Is this a continuation of some previous conversation?

In general, the Java IO classes found under java.io are not interruptible. There are newer (and more complex) classes in javax.nio and its subpackages, some of which are interruptible. So if you need interruptible Java IO, you should probably look there. Using tradtional IO there were a number of possible attempted workarounds, each of which had some bug or another making it unsuitable for general use.

However, it sounds like the problem you're experiencing is when the JVM is sending something, and some C code is receiving. Communicating via a socket I suppose? Having interruptible IO on the Java side won't help you much there, I think, as it's the C code that you want to return if no new bytes are available from the socket. Assuming I've guessed correctly at what you're talking about. What is this "cooking" you refer to?

[Henry Wong]

Still... I am not sure how this is related to threads or synchronization. Unless this is some continuation of another topic here. If this is the case, please continue the discussion in that topic.

In the meantime, I am going to just close this topic, as I am not sure where to move this topic.

Henry

[Jim Yingst]

Hm, I hadn't noticed it was posted in Threads. OK, I think IO would make the most sense, so I'll move it there...

[Nicholas Jordan]

The problem is thus:
I am trying to write a heavy-hauler sifting utility. It really needs the Caterpiller 3208 of Solaris to fuction effectively, wildly beyond the capacity of proprietary Windows to do reliability testing on - but I have to do my testing on propietarty Windows as I do not and will not have access to the machine on which it's use is envisioned. The reasons for this are well documented in reliability engineering.

I pulled the post out of another thread because it did not directly apply to that thread did not want to get off on a tangent, that usually confuses too many people and is hard to keep up with.

You have effectively answered my question, I have no choice but to re-compile under nio and do testing on a faster machine. I have a team member who can provide this functionality to my reliability testing, once I get some fathom on how to go about constructing the test harness.

The book Java Threads - O'Rielly, shows the loop-times collapse under heavy loading when run on Solaris,... my underlying concern is to design test-harness that will run on winnie, that can provide realistic design scenarios without heavy skewing due to uni-processor/massively-parallel architecture differences.

Conceptually, from a reliability engineering view, I know this problem inside out. Did you see the recent work on the Titanic accident on PBS ?

It's classifiable as reliabilty engineering, which doesn't care whodid it, only that it becomes preventable and discoverable.
[ December 24, 2006: Message edited by: Nicholas Jordan ]

[Nicholas Jordan]

Originally posted by Jim Yingst:
It's difficult to tell what you're talking about here

Interruptability of io, as posted, which I intended to work the conversations around to addressing reliabilty issues,(which is where this really belongs as I understand it) such as:

each of which had some bug or another making it unsuitable for general use.

It's reliablility probing, in advance of any use, that I am attempting to achieve. Solaris has a profoundly more reliable kernel io routines than proprietay windows, but I have to do my prototyping on proprietary windows and not look like 'user is a twit' when I send code up for testing.

Propietary windows hangs routinely, I just understand machines by nature and can see that when the box hangs, we have a reliability issue.

What is this "cooking" you refer to?

That was just employment of casual, conversational style to label "Achieve design performance goals."

[ December 09, 2006: Message edited by: Nicholas Jordan ]
[ December 22, 2006: Message edited by: Nicholas Jordan ]

[Jim Yingst]

[Jim]: What is this "cooking" you refer to?

[Nicholas]: That was just employment of casual, conversational style to label " achieve design performance goals "

Ummm, OK. And yet, I still have no idea what those goals are. And therefore, no idea what you actually mean.

[Nicholas Jordan]

Originally posted by Jim Yingst:
[Jim]: What is this "cooking" you refer to?

[Nicholas]: That was just employment of casual, conversational style to label " achieve design performance goals "

Ummm, OK. And yet, I still have no idea what those goals are. And therefore, no idea what you actually mean.

Non-blocking io.:

Is there a function in gcc to detect a keyboard hit? Windows provides a function _kbhit(). It operates in non-blocking mode, returns 0 until the user hits a key on the keyboard.

In other words, how much processor loading does Scanner ..... uh,.... can it even do non-blocking reading of System.in

[Henry Wong]

Originally posted by Nicholas Jordan:

In other words, how much processor loading does Scanner ..... uh,.... can it even do non-blocking reading of System.in

Interruptible I/O, and non-blocking I/O, are two different things.

For non-blocking I/O, consider using the NIO package.

Henry

[Jim Yingst]

It's true that interruptible and non-blocking are not the same thing, but NIO does have some support for both, often in the same classes. SelectableChannel for example implements InterruptibleChannel and also has a configureBlocking() method. However the NIO nonblocking and interruptible functionality tends to be clustered around sockets - they don't really offer either for files or System.in, as far as I know.

[Henry Wong]

Good point... I totally forgot about that. Been using it for socket streams and I just assumed that it work for all stream types.


Anyway, then I guess this topic was originally *correctly* posted in the threads forum after all -- as threading is a common way to read/write I/O in a non-blocking manner.

Henry

[Nicholas Jordan]

Originally posted by Henry Wong:
Anyway, then I guess this topic was originally *correctly* posted in the threads forum after all -- as threading is a common way to read/write I/O in a non-blocking manner.

Henry

Can I engage my regular style then ?

I am sure you know what I intend by this, it takes a certain approach to be effective on this type of coding arena....

I call it thirteen mirrors, after Dr.Stroustrup's Fifteen Ways to Stack a Cat (minus two for the obvious right way and wrong way leaves thirteen ways, which seem to be mostly mirrors on the same central problem)

[Henry Wong]

Originally posted by Nicholas Jordan:

Can I engage my regular style then ?

I am sure you know what I intend by this, it takes a certain approach to be effective on this type of coding arena....

I call it thirteen mirrors, after Dr.Stroustrup's Fifteen Ways to Stack a Cat (minus two for the obvious right way and wrong way leaves thirteen ways, which seem to be mostly mirrors on the same central problem)

Nicholas,

It's probably because I didn't have my morning coffee yet, or maybe my mind is too focused on gift wrapping at the moment, but ... I am not sure to what you are referring to. I am assuming there is an article, written by Dr. Stroustrup, which talks about threading or I/O?

Henry

[Nicholas Jordan]

Originally posted by Henry Wong:


Nicholas,

It's probably because I didn't have my morning coffee yet, or maybe my mind is too focused on gift wrapping at the moment, but ... I am not sure to what you are referring to. I am assuming there is an article, written by Dr. Stroustrup, which talks about threading or I/O?

Henry

The question asks you to set the style I will use in questioning about threads. The article, written by Dr. Stroustrup, carries the title fifteen ways to stack a cat. I took this as a metaphor, being an abstraction of many ways of asking the same question, which may influence how it is answered.

A highly constrained manner of questioning may leave avenues unexplored.

This was my sole intent in the original wording.



No other connotation was expected.

Nick
[ April 20, 2007: Message edited by: Nicholas Jordan ]

[Nicholas Jordan]

Originally posted by Jim Yingst:
It's difficult to tell what you're talking about here, Nicholas. There seems to be some context which you're assuming we know about - we don't. Well, I don't.
[Nicholas]: Are you saying
Is who saying? Is this a continuation of some previous conversation?

You guys were extremely helpfull to me - I have moved on to direct work on some lofty goals for my project, and have been wanting to go back and address this. One site I am using advises (as style guide)

If you have a new question, don't reply to an old post, but compose a new email

and that is what I was doing when I did this. And,

context which you're assuming we know about

Can be constructed from the topic of the post and the opening question.

I thought this was clear. I come back now to assure all I had pristine intentions and sought to don't reply to an old post, but compose a new (thread)
The site where I got this cite ( no pun intended ) filled with a roster of degreed workers or candidates for such and advises that thousands of people are reading the list. post accordingly.

Having interruptible IO on the Java side won't help you much there, I think, as it's the C code that you want to return if no new bytes are available from the socket.

Well, yes ... after contemplation, this is exactly the question I was asking, but the beginner blunder (in phrasing the question) derives from (the challenge of) maintaining a way for the operator to abandon execution at some - arbitrary and indefinite - promptly and reliably, but reading from the keyboard often has an apriori that the operator is going to type something in.

After contemplation, I considered that I should maybe run my app from a gui.

Assuming I've guessed correctly at what you're talking about.

Your working of the question was insightful, generally though I am aprehensive about the user trying to say that I did something wrong because of some sort of situation that I could have anticipated and handled reliably by exceptions, logging, program error message or termination or some as yet other undiscovered approach.

Suffice it to say I deal with some difficult individuals routinely, but the intelligent person, when confronted with failure, can become inventive at blaming others. It is a problem in reliability engineering.

Here I was trying to not have System.in hang, rendering my attempts to deal with unforseen situations stuck in a hung box. In another post, I advised thread.interrupt on a thread blocking on System.in .... then later I read that doing this is unreliable and results in undefined behavior.

This is the " what you're talking about here, Nicholas. There seems to be some context which you're assuming we know about " Which I sort of assumed everyone would intrinsically proceed the conversation in.

I apparently failed in this expectation, and have come back to ( et cetera .....)

What is this "cooking" you refer to?

That was idiomatic. Dare I explain full tilt boogie ?

In general, the Java IO classes found under java.io are not interruptible. There are newer (and more complex) classes in javax.nio and its subpackages, some of which are interruptible. So if you need interruptible Java IO, you should probably look there. Using tradtional IO there were a number of possible attempted workarounds, each of which had some bug or another making it unsuitable for general use.

Are there any of them that will sit on the keyboard while other threads are doing other things, but in doing so not make the system become unstable if it comes time for the program to exit and nothing has been typed in.

as it's the C code that you want to return if no new bytes

Well, I think this is what I want to do - but I do not want to code the program under the run-time restriction that it can only be run from the network.

Since last posting, I have been forced to get a new machine and a new broadband uplink. I notice the new os will run dot jar files that have a main as an executable and is remarkable adept at understanding and running Java. This is an asset I did not have when originally posting this question.

[Nicholas Jordan]

Originally posted by Henry Wong:
Good point... I totally forgot about that. Been using it for socket streams and I just assumed that it work for all stream types.

Anyway, then I guess this topic was originally *correctly* posted in the threads forum after all -- as threading is a common way to read/write I/O in a non-blocking manner.

Henry

I have been worried about this, I don't think we can strictly isolate the question - at least as I originally intended it - as either.

Bearing in mind that my skills are limited and I was doing my best under overloaded thinking from not have all of my program concepted, I think we can make dramatic progress on what I was trying to achieve by addressing:

Interruptible I/O, and non-blocking I/O, are two different things.

I would put a question forward, but do not want to limit the arena of examination: Why is there any difference ?