Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (711)
Games in Android Showcase (213)
games submitted by our members
Games in WIP (785)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  NIO and wait share interrupt flag >:(  (Read 1365 times)
0 Members and 1 Guest are viewing this topic.
Offline blahblahblahh

JGO Coder

Medals: 1

« Posted 2005-04-17 09:43:18 »

In a way, I can't believe it's taken me this long to realise the horror of this setup, but I've just been bitten by it for the first time:

  NIO and Object.wait() share the same messaging primitive, so you can only use one or the other, not both...

Thinking about it now, I'm lost for words: I must be missing something obvious, because it's insanely stupid otherwise.

To make NIO work properly, you need to interrupt your threads, since Sun (in their infinite wisdom) decided to allow NIO to block indefinitely if you chose to touch the selector (IIRC there's no particular reason for this, other than that it made it easier for them to implement their own API).

But that means you cannot use wait/notify anywhere in your select'ing thread, because the JVM has no means to distinguish between "interrupt any blocked NIO" and "interrupt any blocked monitor". And I've just tried using a select'ing thread that, deep down in other code many classes away, performs a wait() for a brief period.

(yes, I know I shouldn't, and I will convert it to not using wait eventually and being purely asynch, but there was no reason why wait shouldn't work that I could see at the time and it would save me significant implementation time for now, at the cost of some performance at runtime).

I'm now sitting here wondering if I can think up a hack to workaround this that doesn't have some obscure synchronization bug in it Sad.

...or if the GrexEngine selectors need to be rewritten not to ever ever interrupt (which I don't think is possible) or to do extra checks before interrupting using some internal hack to make up for the fact that Sun shared the blocking flag between two totally unrelated systems Sad.

Any ideas would be welcome at this point, especially if someone spots an obvious mistake I'm making

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder

Medals: 1

« Reply #1 - Posted 2005-04-17 09:46:43 »

PS: I can see one obvious way out: getting the GrexEngine core rewritten so that it uses select(long) everywhere is *a* solution but practically useless (and not something that would be worth doing to the GE I suspect) ... in order to make services responsive, that long would have to be around 1 ms, or much less, so effectively you wouldn't have a selector at all but a highly inefficient poller.

malloc will be first against the wall when the revolution comes...
Offline kevglass

« JGO Spiffy Duke »

Medals: 319
Projects: 25
Exp: 22 years

Coder, Trainee Pixel Artist, Game Reviewer

« Reply #2 - Posted 2005-04-17 09:48:50 »

To me, sounds like misuse of the interrupting really. If you're interrupting a thread its because you know its waiting in a state that is now invalidated because of some other event.

If you're not sure what state its in how come you're interrupting it?

Hmm.. maybe I've just only ever had naive use for it in the past.


Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline blahblahblahh

JGO Coder

Medals: 1

« Reply #3 - Posted 2005-04-17 10:01:34 »

Ah! Found it Smiley. Selector.wakeup (maybe...haven't checked fully yet)

But ... now I need to go and find *why* the GE base-service I'm using doesn't use it, but instead uses interrupt Huh. Perhaps...wakeup didn't work on all platforms at some point, and this is a legacy workaround?

/me needs to get hold of the design notes for the GE internals and check...

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder

Medals: 1

« Reply #4 - Posted 2005-04-17 10:11:54 »

/me has been very stupid

The GE I/O code all uses wakeup, as you would expect.

But... the base service I'm extending is a threaded class that accepts workloads asynchronously (nothing to do with NIO). It's such a basic class that I had been extending without even bothering to look at it carefully Embarrassed

It needs to idle whilst there's no work to do, and the base class has a sleep( 10 seconds ), whilst the work-accepting method does an interrupt each time new work comes in.

This should, AFAICS, be a wait-on-incoming-queue and notify-when-queue-added-to. The fact that it's interrupting instead of using wait/notify as you'd expect is what then caused pain later on, and caused this mess.

/me goes off to check if there's a particular reason it isn't wait/notifying...

malloc will be first against the wall when the revolution comes...
Offline Jeff

JGO Coder

Got any cats?

« Reply #5 - Posted 2005-04-18 03:56:52 »


Thats just BAD Java code.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!
Pages: [1]
  ignore  |  Print  
You cannot reply to this message, because it is very, very old.

Archive (10 views)
2017-02-27 19:41:49

Riven (24 views)
2017-02-27 17:26:59

numerical (401 views)
2017-02-21 07:32:16

numerical (402 views)
2017-02-21 07:31:46

theagentd (517 views)
2017-02-18 13:42:33

theagentd (513 views)
2017-02-18 13:35:16

h.pernpeintner (1678 views)
2017-01-24 22:39:11

h.pernpeintner (1660 views)
2017-01-24 22:38:32

Galdo (2226 views)
2017-01-12 13:44:09

Archive (2176 views)
2017-01-02 05:31:41
List of Learning Resources
by elect
2016-09-09 09:47:55

List of Learning Resources
by elect
2016-09-08 09:47:20

List of Learning Resources
by elect
2016-09-08 09:46:51

List of Learning Resources
by elect
2016-09-08 09:46:27

List of Learning Resources
by elect
2016-09-08 09:45:41

List of Learning Resources
by elect
2016-09-08 08:39:20

List of Learning Resources
by elect
2016-09-08 08:38:19

Rendering resources
by Roquen
2016-08-08 05:55:21 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!