-
Notifications
You must be signed in to change notification settings - Fork 128
Conversation
Is this related with the Node.js compatibility layer? :-P If so, I think it would be better to name tbe folder 'node_modules' to make it more similar, specially since on NodeOS qe talked about the posibility to add an option to move all built-ins on external files... |
@piranna do you mean |
ceb9147
to
562b7f4
Compare
Wiiii! :-)
Well, not exactly... |
Ah, I see. I like to do |
Me too ;-) Seems to be the "official" way to clean-up the dependencies but I find it an ugly hack, since it should be done with |
I was able to make a basic |
@facekapow nice, just create a new branch from this one, then we can merge one PR into another.. or, actually, I'll just merge this. Wanted to add a few more builtin modules here, but I'll add them separately. |
Ok, I'm going to read up more on DNS packets and implement the different records Node uses into |
👍 |
Is there a list of the current ones? I could look for the ones needed by
|
Is there no support for child_process? :-(
|
@piranna nope, not yet at least, |
Yeah, probably it will be the most difficult :-) but this and native modules are heavily used by NodeOS, so seems there's still a long path until there... :-( There's also filesystems mounting specially FUSE and OverlayFS, but this could be later somewhat easy to emulate (polyfill :-P) on Javascript. WebWorkers would be an option to emulate (Javascript only?) processes, since internally they would use their own isolate objects so we don't need to implement process isolation. I don't know if this should/could be implement outside runtime.js core, though. |
Non-javascript code would need to be compiled to WASM, should work in WebWorkers too. Pretty much the same way as in the browser. |
Yeah, but the main problem of compiled modules is when they access to low-level OS resources like the syscalls... I don't think WASM would be able to manage this :-( On the other hand, maybe it would only be a matter of create a C stdlib that correctly access to runtime.js features, or instead better tuneup |
Pretty much the only thing that lives in C++ land is V8, everything else is in JavaScript. So native modules wouldn't be able to do much in that case, and it would be a security issue with user code running in the kernel space. |
Yeah, in fact I found more complicated loading modules from several apps at the same time... :-/ Two options here, process isolation as Chrome does with the plugins, or see if it's possible to offer an API or syscalls that WASM can make use of. |
How would you kill a WebWorker? I've been thinking about how to implement Ctrl+C in the terminal, and I realized that functions can't be killed. Could you kill a WebWorker? |
WASM should be able to just call into javascript directly, I think it's the way it's going to work in the browser. So same API would work for both JS and WASM. |
@facekapow yeah, take a look at this myWorker.terminate(); https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers |
I know about that, I mean, how would you implement WebWorkers? If you do it by threading, how would you implement the threading? If you do it by running them as functions, you can't kill them, can you? |
Node.js is using threading for WebWorkers (although the patch don't finish to land...), so we could use here any of the threading libraries there are. If you want to implement them by using functions, then they are coroutines or greenlets, that AFAIK they can't be killed since they are running on the same thread. I think we want to have here real pre-emtive processes/threads... |
@facekapow yeah kinda like threads, using separate isolates, each worker can have its own event loop/queue. The simplest implementation is cooperative multitasking, scheduler would pick events each time from the different queue. |
Should console log to the stdio or use |
It should use stdio.
|
@facekapow I think stdio, because it can be redirected somewhere. |
No description provided.