src: drop homegrown thread pool, use libplatform #1329
Conversation
| more = uv_run(env->event_loop(), UV_RUN_ONCE); | ||
| v8::platform::PumpMessageLoop(default_platform, isolate); |
There was a problem hiding this comment.
Note to self: this one can be moved into the if (more == false) { branch below.
|
LGTM, if it works. |
Is this |
d47b74f
to
83b5837
Compare
I don't think so. Packagers are a self-help group, we never made any promises what will and won't work between releases. Besides, I don't think any distros currently carry io.js, it's too new! CI: https://jenkins-iojs.nodesource.com/view/iojs/job/iojs+any-pr+multi/431/ |
|
FWIW, amongst the packages I've found - no one resorts to using a shared v8 any longer. It's too painful to manage. |
|
Good to know. In that case we should gut the shared library support from configure and node.gyp. |
|
For what tasks does io.js use its own thread pool versus the one from libuv? |
|
Only V8 tasks at the moment, i.e., background recompilation and concurrent sweeping. Longer term, I want to unify both thread pools (comment). |
|
@bnoordhuis I think removing shared support for v8 is the right way forward. I'll do a PR. Packagers that insist will find a way. |
Drop the homegrown thread pool that was introduced in commit 50839a0
("v8_platform: provide default v8::Platform impl") and use one from
V8's libplatform library. Performance is comparable and it removes
a few hundred lines of code.
The calls to v8::platform::PumpMessageLoop() are currently no-ops
because V8 does not (yet?) use v8::Platform::CallOnForegroundThread().
Packagers that link against a shared libv8 now also need to make
libv8_platform available.
PR-URL: nodejs#1329
Reviewed-By: Fedor Indutny <fedor@indutny.com>
83b5837
to
4a801c2
Compare
| @@ -664,7 +664,7 @@ def configure_v8(o): | |||
| if options.shared_v8_libname: | |||
| o['libraries'] += ['-l%s' % options.shared_v8_libname] | |||
| elif options.shared_v8: | |||
| o['libraries'] += ['-lv8'] | |||
| o['libraries'] += ['-lv8', '-lv8_platform'] | |||
There was a problem hiding this comment.
@bnoordhuis won't this be an issue when providing your own shared libname (since you can only provide one)? I guess it's irrelevant when my shared v8 patch lands..
There was a problem hiding this comment.
Yes, it's an issue. And yes, it won't be an issue any more once shared library support is removed.
Drop the homegrown thread pool that was introduced in commit 50839a0
("v8_platform: provide default v8::Platform impl") and use one from
V8's libplatform library. Performance is comparable and it removes
a few hundred lines of code.
The calls to v8::platform::PumpMessageLoop() are currently no-ops
because V8 does not (yet?) use v8::Platform::CallOnForegroundThread().
Packagers that link against a shared libv8 now also need to make
libv8_platform available.
R=@indutny