Concurrency issue between CleanupSockets and AttachFD #354

Open
franzk opened this Issue Aug 19, 2012 · 2 comments

2 participants

@franzk

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 :-)

@tmm1

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.

@franzk

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)

This...

require 'posix-spawn'
require 'eventmachine'

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

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

  EM::attach(stdin, MyPipe)
end

EM.run do
  execute
end

...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
Merged

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