Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (757)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (843)
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  
  Heads up: SelectionKey.attach() broken ?  (Read 1703 times)
0 Members and 1 Guest are viewing this topic.
Offline blahblahblahh

JGO Coder

Medals: 1

« Posted 2004-06-30 15:36:35 »

(nb: I'm struggling to check the bug parade on this, but it's not searchable for the term "attach" so it's frickin hard; c.f.;action=display;num=1088616088)

I'm fairly confident there's a mean, nasty, evil bug in 1.4.2 whereby SelectionKey's arbitrarily kill their attachments, silently.

The situation I'm in, I just ran a full text search for "attach(" against all source code in the server, and verified that I have a breakpoint (or logging point) on every single line of code where it's called, and yet I'm seeing attachments flip from a LinkedList to null without me touching them.

I think the problem might be that when you reset the interest set for a SelectionKey, sometime later (not immediately) it decides to wipe out it's attachment. I'm trying to construct a case that proves it, but it is definitely time sensitive, which is not surprising since it's probably triggered by the Selector doing something internally. But I might not be able to make a conclusive test case because of the timing-sensitivity Sad.

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

JGO Coder

Medals: 1

« Reply #1 - Posted 2004-06-30 16:55:14 »

Turns out it isn't the interestOps() that kills the attachment, but instead the following.

I was re-registering SelectableChannel's to get a new key every time they were being re-used after having an empty interestOps.

When you re-register an SC, it returns the pre-existing key.

However...the method call:

  register( Selector, ops )

actually delegates to

  register( Selector, ops, null )

which explicitly deletes the attachment. Which is an incredibly stupid way of designing your API - silently deleting attachments. I can't off the top of my head think of any explanation for this behaviour other than:

- it's supposed to be a shorthand for killing attachments (which is stupid because that's the kind of thing we did in C, not in Java, where things are supposed to be done cleanly)

- the API developer was too lazy to write a two-line method body, OR didn't stop to think what the consequences were of using null as a default (in this case, it doesn't mean "use default" it means "delete what was already there").

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

Senior Newbie

Take pity, I'm just a poor blob!

« Reply #2 - Posted 2004-06-30 17:30:59 »

I got caught out by that one as well. The best explanation I could come up with is that its register() not reregister() :-/. I guess on the positive side, at least the javadocs are clear on this point.


An invocation of this convenience method of the form

   sc.register(sel, ops)

behaves in exactly the same way as the invocation

   sc.register(sel, ops, null)
Pages: [1]
  ignore  |  Print  

EgonOlsen (40 views)
2018-06-10 19:43:48

EgonOlsen (21 views)
2018-06-10 19:43:44

EgonOlsen (42 views)
2018-06-10 19:43:20

DesertCoockie (188 views)
2018-05-13 18:23:11

nelsongames (123 views)
2018-04-24 18:15:36

nelsongames (122 views)
2018-04-24 18:14:32

ivj94 (862 views)
2018-03-24 14:47:39

ivj94 (123 views)
2018-03-24 14:46:31

ivj94 (759 views)
2018-03-24 14:43:53

Solater (140 views)
2018-03-17 05:04:08
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05 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!