Concurrency issue between CleanupSockets and AttachFD #354

franzk opened this Issue Aug 19, 2012 · 2 comments

2 participants


The issue is about the Descriptors vector. During operation, CleanupSockets may free the memory where a member of Descriptors points to, so the Descriptors vector contains an invalid pointer for a short time period.

Now I am experiencing the situation that during this small window of time, another thread executes AttachFD. In rare cases, as the invalid pointers of Descriptors may point to "random" data, this random data equals to the FD which is going to be attached - and "adding existing descriptor" is being thrown, but it's a false positive.

This sounds a bit theoretically, but I have an application running which attaches and detaches a lot of file descriptors - and it constantly gets into the described situation :-)


EM internals are not designed to be threadsafe. Which ruby VM are you using?

You can use EM.schedule to ensure attach/detach events happen from the reactor thread.


Ruby 1.9.3 MRI

Finally I figured out a small example script... I am tracking the beginning and the end of CleanupSockets calls ("CLEANUP..." and "done.\n" together with flushes)


require 'posix-spawn'
require 'eventmachine'

class MyPipe < EM::Connection
  def unbind
    sleep(10000) # "forever"

def execute
  pid, stdin, stdout, stderr = POSIX::Spawn.popen4 "mkdir test"

  EM::attach(stdin, MyPipe)
end do

...returns nothing but "CLEANUP..." for me, so the unbound connection somehow interrupts in a way I did not expect. This seems to be the reason for the described "concurrency" issue, because in nested calls, my unbind called EM.attach.

Do I miss something?

@BenV BenV referenced this issue in faye/faye-websocket-ruby Aug 26, 2015

Make sure EM.attach is called on the reactor thread #74

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment