Mochabot log - CommonJS IRC channel: #commonjs on irc.freenode.net

2010-05-17:

[16:11] <Wes--> ashb: ping
[16:15] <ashb> Wes--: yo?
[16:17] <Wes--> ashb: How does flusspferd handle the case where multiple native modules are loaded in different runtimes? Do you ever store state or things like the prototype you get from JS_InitClass() in a DSO's local/global variables?
[16:17] <ashb> we dont.
[16:17] <Wes--> ashb: Also, do you have a mechanism for keeping module instances separate of each other for worker threads?
[16:17] <ashb> handl multiple runtimes that is
[16:18] <ashb> but the JSClass* is cached in a slot off the context
[16:19] <Wes--> Hm, do you do worker threads yet? If so, I guess you replicate the context private when you spawn a new thread?
[16:19] <Wes--> I'm doing some "deep thinking" today about the consequences of native modules with commonjs semantics
[16:19] <Wes--> especially where the interesting intersections are -- sandbox, worker thread, promiscuous thread, runtime
[16:20] <Wes--> Things like the module memo probably should be 'shared' with different semantics than the runtime linker does with global variables
[16:20] <Wes--> Which means coming up with a class of things which should be shared-alike, and naming that class
[16:20] <Wes--> So far, I'm going with "realm" to describe the group of things which sets up the storage boundaries
[16:21] <Wes--> So, a parent and a worker thread would be in different realms
[16:21] <Wes--> and a realm would hold a global variable, a module memo, and a module data store
[16:21] <Wes--> the module memo is what controls singleton-ness
[16:22] <Wes--> the module data store is the replacement for global variables
[16:22] <Wes--> hdon ^^^ btw fwiw ^^^ hdon_
[16:23] <Wes--> secure sandboxes would also be separate realms
[16:24] <Wes--> and script modules would be unique across realms
[16:24] <Wes--> that falls naturally from having a module memo per realm
[16:24] <Wes--> No two realms could also share a JSRuntime, I think that goes without saying
[16:24] <Wes--> But they could share the same OS thread (not worker thread), JSAPI threadsafe semantics notwithstanding
[16:25] <ashb> mmmhmm
[16:27] <Wes--> So, if we were running, say, javascript in the apache threaded MPM, we could perhaps set each "session" up as it's own realm. JavaScript modules could store state data under the global variable. Native modules could store data under the module data store.
[16:27] <Wes--> Actually, I guess, it should just be a "realm data store", nothing moduley about it
[16:27] <ashb> other ethan being keyed on the module
[16:27] <ashb> so that the module doesn't have to worry about namespaceing itself
[16:28] <Wes--> Yeah - although, actually, I just key them on pointer. So, the module can declare a static and take its address (guaranteed unique), or if it's class-based (instead of module based -- class ~ subset of module) we can use the JSClass pointer (since that's also static)
[16:29] <ashb> ah
[16:29] <Wes--> (In my old-school C brain: arbitrary pointer === arbitrary unique pointer-sized int)
[16:29] <ashb> we only have a single two JSClasses for all our natives
[16:29] <ashb> NativeObject and NativeObjectWithEnum (both have the same name to JS)
[16:30] <ashb> giving [object NativeObject]
[16:30] <Wes--> Oh, yeah, that wouldn't work so hot for that, you'd wind up using something else... like maybe the address of the constructor or something for your C++ class
[16:31] <Wes--> FWIW -- jsdb requires multiple runtime support, but it's not necessary to have the same "technology" for the debugger and the debuggee
[16:31] <Wes--> For example, I have been debugging a GPSEE runtime with a plain JSAPI jsdb
[16:31] <ashb> interesting
[16:31] <Wes--> Now I am GPSEE-fying jsdb, so that I can use GPSEE modules to improve the UI
[16:32] <Wes--> In theory, you could have a GPSEE'd Runtime for UI debugging script running flusspferd runtime
[16:32] <ashb> heh
[16:32] <Wes--> this is whey I had to start thinking about extents, BTW
[16:32] <ashb> right screw this - i'm off
[16:32] <Wes--> GPSEE needs to know the JSOBject * of certain prototypes for things like the FFI's cast operators
[16:32] <ashb> bbiab
[16:33] <Wes--> It turns out that sharing objects across runtimes is BAD. :)
[16:33] <Wes--> ashb: Have an extra pint for me. :)

 

 

Logs by date :