There's a node already doing some repetitive works(like setInterval) and network event handling.
I've built another network library in C++ using Boost.Asio and want to use it from node I explained above(with node-ffi and it works well).
Here's the problem. Node has its own event dispatcher and Boost.Asio too. So, after I've invoked the above C++ library from node, because it blocked, no other node code could not be reached and didn't work anymore.
Can I make them to coexist peacefully...?
Asio's io_service::poll_one() works find in some way but there's a better solution.
node-ffi's Async Library Call is perfect for this situation. It says...
node-ffi supports the ability to execute library calls in a different
thread using the libuv library. To use the async support, you invoke
the .async() function on any returned FFI'd function.
Related
hystrixjs is an implementation of Hystrix for NodeJS.
But I'm not able to understand how it works in a single threaded js. How does it handle timing out the task?
The documentation talks about that a bit
Since this library targets nodejs application, it is by far not as
complex as the java implementation (remember... just one thread... no
concurrency, at least most of the time...). So how does it accomplish
the goals outlined above:
wraps all promise-based calls to external systems (or "dependencies") in a "Command"
Does that mean all the library is just run the promise and letting node handle the multi threading part(like network calls being handled by OS threads)?
I'm a rust newbie, want to write a node.js package related to database querying.
I'm using napi-rs for the package.
In node.js we have own async stuff, in rust we have similar thing called "tokio" for async stuff.
I want to create ORM for node.js, and learn rust at the same time, so idea is to construct queries on node.js side and perform them on rust side, give response back to node.
I see two ways:
Use tokio with tokio-postgres
Not to use tokio, instead to write own database adapter library which will rely on node async functionality and node sockets. Not even sure if I can do this but can try. Not sure if that makes sense.
First way is way more simple, but will it work? Is efficient to include tokio to node.js package?
execute_tokio_future method of napi works just perfect! Details on how to use it I found here: https://forum.safedev.org/t/adventures-in-rust-node-js-and-safe/2959/10
I was able to get benchmark with better results using rust addon than a node library, so the idea paid off.
I wonder how I can implement an async/await version of the Directory.CreateDirectory method in the System.IO namespace?
CreateDirectory is an odd scenario. It would be ideal to have an asynchronous version built-in, particularly for opening/creating directories on a network drive.
Normally, you would be able to P/Invoke an asynchronous Win32 API if the BCL doesn't support async directly. However, in this case, the Win32 API does not actually expose asynchronous APIs for directories. So you'd have to go even lower - probably calling the file system driver directly (all device drivers support async I/O, so that would certainly work).
So, although it's not ideal, you're probably better off in this case just making a fake async method, i.e., wrapping the call in Task.Run.
On a side note, the Windows Store-style directory APIs are asynchronous. It's possible that they're calling beneath the Win32 API, but I actually rather doubt it - I'd expect they're implemented as fake asynchronous methods.
I look for the package that allows to work with redis in synchronous manner. The problem is I don't want to rewrite the code for async flow.
The possible solution is
Find synchronous library to work with redis.
Implement a middle layer script in some synchronous language and communicate with this script by synchronous execution operation.
I tried to use synchronize with no success so far.
You may want to give a try at co, which will let you write non-blocking code using almost any existing node library. Here is a specific example using node-redis.
Please note that co requires node 0.11.x (with --harmony flag) or 0.10.x with a wrapper like gnode.
We have a large c++ codebase that I'm porting onto Android. We had the foresight to abstract various platform-dependent features (threading, file access etc), so the process involves the gradual implementation of Android-appropriate code functions in the NDK
I was getting on reasonably well until I realised that semaphores (used in our core code) don't appear to have an implementation in the NDK.
I was wondering if it were possible under this (and possibly other) circumstances to implement the required functionlity (if it exists) in the SDK, e.g a 'Java' Semaphore and pass it down to the native code via the JNI interface for the native code to operate on it via appropriate callbacks.
Is there a reason why this might be inadviseable for synchronisation purposes?
Thanks
Have a bad news guys. Semaphore isn't implemented on android version of pthread google source
As for me flock(2) is an answer. But there is potential problem where you are trying to lock same file from different users.
Probably the worst consequence of using a Java-based implementation that you pass to your native code is that your semaphore operations will be very slow since they have to cross the JNI boundary.
Is there any reason why you can't use POSIX semaphores? See semaphore.h from the NDK's headers.