Stephen Bowline
2012-05-04 16:23:52 UTC
I've got a middleware library that I use to communicate with a server using
both synchronous and asynchronous socket IO. I've had really good luck
with this architecture, embedding the middleware in multithreaded C++/Qt
applications and python; however, I'm really struggling getting it to work
with the middleware lib loaded in a node.js module.
The node community hasn't been very responsive to my queries, so I'm hoping
the asio community can shed some light on this.
First of all, I'm using boost::asio 1.47.0 on Red Hat Linux with gcc 4.6.1
and node.js 0.6.12. The first problem I have is that asio routinely seg
faults (but not always) when constructing a basic_io_stream socket. The
op_queue ends up with gargage pointers in back_. If it doesn't crash, then
the queue never processes handlers. I'm pretty sure there is some
threading issue at play here, but I'm not having much luck narrowing it
down.
I've tried a single threaded such that there is only one io_service in the
node module with hopes of just polling manually with the node event loop.
But this still yields non-deterministic memory corruption. Valgrind only
reports uninitialized memory in op_queue - which isn't true - I can step
through and see clearly that the members, and what back_ is assigned to is
initialized.
I've also tried instantiating the io_service and the middleware class from
with a boost::thread blocking on a mutex so that the node module will wait
until construction is fully complete. This tends to reduce the likelihood
of the seg fault, but it doesn't go away. It's sooo weird. And even if the
seg faults do not complete, I'm still stuck with the handler problem. They
will not process. I'm not familiar at all with epoll() and how it works at
a low level, but I'm beginning to think that it's just not possible to mix
asio with node. Both are using the epoll() mechanism. That might be OK if
I could get the middleware module to run in its own thread with blocking IO,
but alas...
Any thoughts out there? The middleware isn't especially complicated, so I
can rewrite it using native sockets or somthing, but I'd really like to keep
it the same so I can embed it unchanged in a multitude of environments.
-stephen
both synchronous and asynchronous socket IO. I've had really good luck
with this architecture, embedding the middleware in multithreaded C++/Qt
applications and python; however, I'm really struggling getting it to work
with the middleware lib loaded in a node.js module.
The node community hasn't been very responsive to my queries, so I'm hoping
the asio community can shed some light on this.
First of all, I'm using boost::asio 1.47.0 on Red Hat Linux with gcc 4.6.1
and node.js 0.6.12. The first problem I have is that asio routinely seg
faults (but not always) when constructing a basic_io_stream socket. The
op_queue ends up with gargage pointers in back_. If it doesn't crash, then
the queue never processes handlers. I'm pretty sure there is some
threading issue at play here, but I'm not having much luck narrowing it
down.
I've tried a single threaded such that there is only one io_service in the
node module with hopes of just polling manually with the node event loop.
But this still yields non-deterministic memory corruption. Valgrind only
reports uninitialized memory in op_queue - which isn't true - I can step
through and see clearly that the members, and what back_ is assigned to is
initialized.
I've also tried instantiating the io_service and the middleware class from
with a boost::thread blocking on a mutex so that the node module will wait
until construction is fully complete. This tends to reduce the likelihood
of the seg fault, but it doesn't go away. It's sooo weird. And even if the
seg faults do not complete, I'm still stuck with the handler problem. They
will not process. I'm not familiar at all with epoll() and how it works at
a low level, but I'm beginning to think that it's just not possible to mix
asio with node. Both are using the epoll() mechanism. That might be OK if
I could get the middleware module to run in its own thread with blocking IO,
but alas...
Any thoughts out there? The middleware isn't especially complicated, so I
can rewrite it using native sockets or somthing, but I'd really like to keep
it the same so I can embed it unchanged in a multitude of environments.
-stephen