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)
class MyPipe < EM::Connection
sleep(10000) # "forever"
pid, stdin, stdout, stderr = POSIX::Spawn.popen4 "mkdir test"
...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?