Support simple extension functions written in JavaScript #5
Conversation
For asynchroneous calls, the callbacks are performed on the main event loop while the worker thread is blocked on a mutex. At the moment, only boolean, numeric and string values can be passed between the XSLT processor and the JavaScript function. Other types would be highly desirable, but might require a lot more work.
This ensures that the main event loop will terminate without a call to process.exit. And it satisfies the requirement from the manual that the async must be closed before being deallocated. Closing on the v8 thread avoids an abort when v8 itself shuts down, details unknown.
|
OK, apparently CI is unhappy about how I set the flag for C++11 support. This question on Stack Overflow might help to get things running on Mac, but doesn't seem to have anything to offer for here. Any better suggestions? |
|
I didn't read your whole commits, but I guess c++11 is required for lambda functions ? During my tests for this functionality, it seemed necessary to use lambda functions to wap V8 functions into extension functions compatible with libxslt. I spoke about functors in the comment of the commit by mistake I actually meant lambda function. I saw this promising post about building node extensions with C++11, and that is the limit of my knowledge on this question :( I have absolutely no problem accepting the PR with only simple types support. Only the build issue has to be fixed and the documentation completed. Beware that the README.md should not be edited directly, instead you should edit README.hbs then run 'npm run-script doc'. The only thing bothering me is that this is a significant jump in code complexity for this project. Honestly, I am not a competent C++ dev, and I don't feel like maintaining another developer's code in this technology. Anyway I lack the time to do so. Would you agree to be registered as contributor to the project ? |
|
I don't need lambda functions. I'm mostly using C++11 because I like I guess the Travis problem lies in the fact that it's using GCC 4.6.3 which doesn't know I'd gladly come aboard to support extension function in the future, but since I have near to no knowledge about V8, NAN and the whole NPM development and deployment workflow, I'd be looking for guidance in those areas. And I won't make any binding promises. I'f I'm too busy to address some issue, then that's that. I don't mind friendly reminders if I forget something, though. |
|
I changed the syntax to C++03 but there appears to be some race condition, probably related to how I close the async handle. Not sure how to do this correctly. I saw this error before when I closed the handle in the destructor. |
The core idea is that we allocate the context before we apply the stylesheet. That way we can store task-specific stuff in that context, like the information whether we are single- or multi-threaded. We might also be storing per-context functions there.
As suggested in #2, here is my stab at getting extension functions implemented. If you don't feel like merging this until more types are supported, let me know. But I'm not sure I'll be able to provide support for additional types any time soon, if at all.