[WIP] WebWorker implementation. #1331
Conversation
ry
force-pushed
the
workers
branch
2 times, most recently
from
16559d6 to
95c6b40
Compare
There was a problem hiding this comment.
Just thinking too, IIRC, TypeScript can load itself into a web worker to increase its performance. I think that is to help it be non-blocking in a browser, but there might be other aspects as well. It is worth researching a bit more to see if we can further improve the compilers performance.
| @@ -71,3 +72,8 @@ window.TextEncoder = textEncoding.TextEncoder; | |||
| export type TextEncoder = textEncoding.TextEncoder; | |||
| window.TextDecoder = textEncoding.TextDecoder; | |||
| export type TextDecoder = textEncoding.TextDecoder; | |||
|
|
|||
| window.workerMain = workers.workerMain; | |||
| // TODO These shouldn't be available in main isolate. | |||
There was a problem hiding this comment.
I think we will have to create a seperate global module for the compiler isolate when we get there. There is clearly a lot of stuff that isn't necessary in order to support just the compiler.
|
I have no idea why introduce another pair of channels |
This reverts commit e976b3e. There is nothing technically wrong with this commit, but it's adding complexity to a big refactor (native ES modules denoland#975). Since it's not necessary and simply a philosophical preference, I will revert for now and try to bring it back later.
This reverts commit 3d03f5b.
Only accessible from Rust currently. fixes wip wip test_rs passes fucking works
|
this code is included in #1460 |
Only accessible from Rust currently.
This is part of the effort to get native ES modules #975