Thanks Chuck, wouth checking I'm hoping there isn't much concurrency ...
turning out difficult running, in the mean time did you verify the example works fine under JRuby 9.1?

../jruby/bin/jruby -rfcntl -Ilib examples/echo_tcp.rb 
NameError: uninitialized constant Fcntl::O_NOCTTY
       const_missing at org/jruby/RubyModule.java:3392
  <module:Constants> at /home/kares/workspace/oss/ruby-io/lib/io/platforms/common_constants.rb:56
  <module:Platforms> at /home/kares/workspace/oss/ruby-io/lib/io/platforms/common_constants.rb:3
          <class:IO> at /home/kares/workspace/oss/ruby-io/lib/io/platforms/common_constants.rb:2
              <main> at /home/kares/workspace/oss/ruby-io/lib/io/platforms/common_constants.rb:1

followed by :

FFI::NotFoundError: Function 'disconnectx' not found in [libc.so.6]
            attach_function at /home/kares/workspace/oss/jruby/lib/ruby/stdlib/ffi/library.rb:241
         <module:Platforms> at /home/kares/workspace/oss/ruby-io/lib/io/platforms/common/ffi.rb:32
                 <class:IO> at /home/kares/workspace/oss/ruby-io/lib/io/platforms/common/ffi.rb:2
                     <main> at /home/kares/workspace/oss/ruby-io/lib/io/platforms/common/ffi.rb:1

Perhaps it's time we finally dumped the CRuby impl of set.rb and made a proper one that's concurrency-friendly and not based on Hash.

@headius this is a bug with the set.rb rewrite (to .java) on master - hopefully not concurrency related

@kares Unfortunately I can't run it on any 9.1.x release because of issue 4920. That Fiber fix hasn't been part of any release yet.

As for the O_NOCTTY, I'm not seeing that on my OSX or Linux box. The disconnectx error must be from you running this on linux. I'll check this morning (I only test on my linux image about once per week) and push a fix. Sorry for distracting from the real problem!

If you have access to an OSX machine, the current code should run fine.

And I'll add a comment here like I did in IRC. There is no concurrent access to this SortedSet. It is only ever accessed by the thread running the IOLoop so there should not be any races.

From my testing yesterday, what I see happening is that the superclass's hash is adding the value. That's why size returns the values that it does, because SortedSet relies on the hash.size(). But when running to_a, it generates the array from the TreeSet order variable. This tells me that the value is somehow being dropped from the TreeSet. Perhaps it thinks it is adding a duplicate and just overwrites another value? Anyway, the problem is the disparity between the hash and the treeset.

Thanks Chuck, I assumed there isn't much concurrency but wanted to double check.
will definitely fix this one, we just need to be able to reproduce - ideally on Linux.
I do have a MacBook box around but its not setup - thus I rather wait if you're able to get this going...

@kares Pull latest master and try again. Until I figure out my epoll issues on linux I have forced all platforms to use select. On my Ubuntu 17.10 box the example code now runs to completion under MRI. I do not have jruby installed and working... I keep getting some complaint about trustedanchors that I haven't been able to fix yet.

Let me know if you need anything else.

all reproducing now - the issue relates to trying to implement a proper SortedSet by JRuby ...
a one that does sort its elements upon insertion (unlike MRI's set.rb), doing so Java's TreeSet has a glitch: compare should align with equals. which is not the case for IO's Timer :

        def <=>(other)
          @fire_time <=> other.fire_time
        end

        def ==(other)
          # need a more specific equivalence test since multiple timers could be
          # scheduled to go off at exactly the same time
          #      @fire_time == other.fire_time &&
          #      @callback == other.callback &&
          #      @periodical == other.periodical?
          object_id == other.object_id
        end

so for the underlying Hash instances are never equal but for the TreeSet (order) they might be (<=>)
... which I can confirm if I adjust (no more failures) :

        def <=>(other)
          cmp = @fire_time <=> other.fire_time
          cmp.zero? ? object_id <=> other.object_id : cmp
        end

this is a bug (regression) of not having proper MRI compat on master -> will either need to blindly follow set.rb's SortedSet inefficiencies and not play smart or adjust the TreeSet impl to do additional equal check

I will make your modification to my code for now. Do you plan to make the native Java SortedSet conform to the Ruby semantics?

Do you plan to make the native Java SortedSet conform to the Ruby semantics?

yep MRI compat first - will use your original <=> + == implementation as a guideline/test-case ... thus :

will either need to blindly follow set.rb's SortedSet inefficiencies and not play smart or adjust the TreeSet impl to do additional equal check

@kares I guess the two options here are to implement our own Set that matches MRI semantics (i.e. not wrap slightly-off Java sets) or add a linked list for insertion ordering. The latter would still be more efficient than a fully-wrapped Hash but the former would be the most efficient. We might also take this opportunity to implement direct addressing as added in Ruby 2.4, which we could them reapply to our Hash.