Compatibility with other libraries using epoll

[Stephen D. Bowline]

Marc, thank you for taking the time to look over my posts.  I really
appreciate it.

> Your description is not exactly detailed. I'd say having a valgrind message
> telling you something that you disagree with is a very very good hint that
> there is something in your code that you don't understand, and is buggy.

  There is definitely something going on that I don't understand.  The
valgrind error is a conditional jump on uninitialised memory - memory
that I know to be initialised, but if the pointer I know to be
initialised is overwritten by an address that isn't - then that would
be my explanation.

  However...this is one part that is reallllly weird.  I've used two
different debuggers to set hardware watchpoints on this memory to try
and find out who and why it's altered.  The address, as verified by
/proc/<pid>/maps is definitely in the heap; however, the debuggers
believe the memory to be on the stack.  OK, buggy debuggers, but gdb 7
shows a somewhat nonsensical stack (the last address is 0x000000000)
all the while things seem normal.

  I've heard that some pthreads functions write non-standard stack
data, so maybe this is what's happening.  I don't know.  I've not run
across anything like this before, and like I said in the posts, this
whole thing works beautifully in other contexts - just not as a
Node.js module.

>>   Am I wasting my time trying to get asio to work within another
>> library that is using libev for event handling?
>
> There is no known mechanism in how they could interfere via epoll -
> multiple epoll users in the same thread or process are routine and
> commonly implemented.

  That is essential info for me.  Thank you!  It gives me confidence
that the problem can be solved and there's not some crazy
incompatibility.


-stephen