On Mon, Jun 10, 2013 at 10:13 AM, Tim Wu <[email protected]> wrote: > Hi! > > We're building an embedded system project with NodeJS. > A tough issue we're struggling with is that this system must react a certain > external hardware input signal within 100ms. > > The input signal's event flow from hardware to NodeJS are pretty typical as > below. > > K1. interrupt happens and the irq handler at the driver enqueues an event > K2. awake user processes waiting for events > K3. processes sleeping in poll or read handler got awaken. They dequeue the > event and return. > > U1. When an event is ready to read for user process, the I/O watcher > callback ( in nodejs native addon) got called. > U2. I/O watcher handler call the pre-registered JS callbacks. In our case, > all the logics are processed here. > > The processor is 800Mhz ARM9. Most of the time, the CPU utilization is low > than 10%(observed from top). > We did some time measurements. Mostly the time elapsed between K1 and U2 > is around 20ms~30ms however sometimes it gets over 120ms. > > After some investigation, we found that the logic processing callback is > probably blocked/delayed by other JS callbacks. > > Based on our understanding, all JS functions are performed in single event > loop. We guess that if we want certain functions not to be blocked, we > should run it in another loop run by another thread. So we soon add some > code like the following. > > 1. create a new event loop via ev_loop_new() > 2. attach the io watcher into this loop via ev_io_start > 3. run this loop in a new created thread. > > This thread basically works and the IO watcher callbacks get run very soon > once upon interrupt happens. However, it crashes when we call standard V8 > functions to create JS objects like String::New. > > We are stuck here. Besides the question above, we're even not sure if our > approach is right. > Hope someone experienced can give us tips. Thanks you.
V8 (node.js too) is not thread-safe. That is, you cannot call v8::* functions outside of the main thread. (There is a v8::Locker class but it's probably not what you want, it's essentially a big serializing mutex.) You mention that your logic processing callback doesn't always run in a timely manner. Have you profiled where your application is spending its time with the --prof switch or the perf tool? Take a look at deps/v8/tools. linux-tick-processor is for processing the v8.log file that --prof generates. ll_prof.py is a script that knows hows to combine the output of --prof with perf.data files, for when you need more fine-grained profiling data. (--prof is a sampling profiler with a granularity of ~1 ms.) As to having multiple threads, there are two possible approaches: * Something like threads-a-gogo which spins up worker threads that run JS code in a restricted environment. * Multiple processes that communicate with each other over UNIX pipes. Support for that is baked into the child_process module. One caveat is that process.send() serializes your data to JSON and deserializes it again in the other process, which can be slow for large messages. If that's an issue, you can set up a channel manually and transmit only binary data (i.e. Buffers.) -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
