This project is read-only.

Feature Requests

Topics: Developer Forum, Project Management Forum, User Forum
Jul 4, 2011 at 2:43 AM

Besides the Debug API, which I do intend to add eventually (Mozilla's MDC documentation is practically useless).

What are some other features that you would like to see added to smnet?
--What do you like about smnet?
--What do you dislike about smnet?

What problems have you encountered using smnet in different situations?

Mar 5, 2012 at 6:38 PM
Edited Mar 5, 2012 at 6:42 PM

Hello SilverX,

Is the project still active? Because, i will use it in an larger community project. Is the offer for Feature requests still available?
but it seems, the wrapper is very complete. As i see, this features are all available:

- Create an c# class-instance in js.
- Use an created class-instance in c# for js. (passing to engine)
- Use shared c# objects in the js-engine. That means: Multiple js-runtimes accesses the same global/shared/c#-objects.

Not tried yet, but is this possible?
- Each runtime have its own expandos for global/shared objects. For example, if runtime1 set GlobalStructure.AGlobalObject.PropertyDoesNotExists = 5, that runtime2 has no access to "PropertyDoesNotExists"? It should set only his own one, if wished. This is importand for isolating the runtimes. Shared objects itself are very imporant.

Maybe you should make the class SMContext "public" or offer the possibility, to make the method "GetParameter"/"SetParamter" public. An workarround in the moment is to write an wrapper-function in js.

I have compiled the spidermonkey c++ library (and nspr library) from original sources in x64 mode, and recompiled  the c++/cli with that lib-file in x64, too(target .NET 4.0). If you are interested in these binaries, let me know.

Greetings from Germany,
Sebastian

Mar 5, 2012 at 7:45 PM

Hi Arakis and thank you for your interest in this project.

In spidermonkey 1.8.5 they added compartments to the runtimes so runtimes are now very isolated and difficult to share objects between (though it is possible). A C# class will appear shared among the different scripts, however C# classes exposed to javascript have their JS object equivalent created on a per-script basis, meaning that C# classes will have a different object pointer in each script. Expando properties will also be applied on a per-script basis. If you have the same C# class initialized within many different scripts, each script will have it's own set of expando properties.

As for making SMContext public, that seems a little unnecessary as the main purpose of the SMContext class is to encapsulate thread-safety. If the script's context pointer is needed, say for custom P/Invoke calls, please use SMScript's public instance property "ContextPtr". Also SMScript provides methods for obtaining a C# class's JS object pointer. For instance classes, SMScript::GetObjectPointer and for static classes SMScript::GetPrototypePointer. I added these functions to the public API so that an embedding application could use  P/Invoke to "hack" the engine to provide any functionality that is not natively supported by the wrapper.

Example:

[DllImport("mozjs185-1.0.dll", CallingConvention = CallingConvention.Cdecl)]
public static extern void JS_GetContextPrivate(IntPtr cx);
//Then when you have a script instance to use:
JS_GetContextPrivate(script.ContextPtr);

So if there is a spidermonkey API call you would like to use it is possible to use smnet to get the data required to use P/Invoke to adapt your own unique twist into the engine.

I hope this helps. Please refer to the documentation for an outline of built-in features.
If there is anything I haven't covered yet please feel free reply or email.

SilverX

Mar 5, 2012 at 8:31 PM
Edited Mar 5, 2012 at 8:32 PM

Hey SilverX,
thank you for the quick reply. This shows me, the that developer(s) (you) have still interest in this project.

What about a method setGlobalVariable/getGlobalVariable in SMScript? I'm sure, setting variables via api is nicer and faster instead of consstructing a javascript-proxy function, and executing it.

Are you interested in my x64 binaries?
Is it true, that there's no more up to date javascript-engine from mozilla? I took for the x64 compilation the original sources, they are from march 2011. Don't worry, spidermonkey is still extremly fast ;)

"If you have the same C# class initialized within many different scripts, each script will have it's own set of expando properties."
- Yes, this is *exactly* what i want! :)

When disposing a SMScript/SMRuntime, wich ways "could" exists, to fragment the memory with garbage objects? Are there *any* way, how a memory leak could be exists? Is there any way, to crash the host process, for example with stack overflow?

Greetings,
Sebastian

Mar 5, 2012 at 10:04 PM

Yes I do have an interest in this project, I have devoted many hours into this library and even though the SVN hasn't been updated in a while I do like to see other developers using it and enjoy helping/explaining whenever I am available :)

The reason the project migrated from a C# P/Invoke library to a C++/CLI mixed library is because there were a couple memory leaks that were seemingly impossible to track down. To the extent of my knowledge (and testing) no memory leaks exist in the current build of the wrapper anymore. However, you as the embedding developer are responsible for calling JS_GC (see the documentation for GC tips, they're near the bottom of the page). The reason for this is because JS_GC is a CPU heavy method and calling it from within smnet itself slowed down code execution by an intolerable amount. smnet uses JS_MaybeGC in many places and this does help keep the memory footprint low but it only GC's if the engine determines it will claim a reasonable amount of memory (how much that is I don't know).

As for custom expando properties on the global object I have added 2 new functions to SMScript, they are GetGlobalProperty and SetGlobalProperty, initial testing ensures that they are working and provide the functionality that you're asking for. I also created another function in SMScript called Invoke, the purpose of this function is to perform JS API P/Invoke calls. I attempted to do so myself and noticed it needs to be wrapped in the thread-safe locking mechanisms otherswise spidermonkey will throw an assertion failure. I will update the SVN repository momentarily. Once you have downloaded the up-to-date source code please take a look at smnet-demo.Program.cs for a demonstration of using the new functions.

Mar 5, 2012 at 10:55 PM

Oh sorry I forgot to address a couple of things. Yes I do believe it is possible to crash the host process, but this will most likey be caused by a mistake in the embedding code or an actual bug in the embedding. Spidermonkey can be sandboxed quite well because scripts are only allowed to access what the embedding application gives them access to. For sanity sake you can wrap all smnet API calls in try/catch blocks, if an exception rarely happens it won't negatively impact performance. Exceptions that occur in "native callbacks" (as they are referred to @ mozilla), are handled internally, so say an exception that happens in a C# method that was accessed from script, and get reported to the SMScript's error reporting event. This is because if an exception occurs during those callbacks the stack gets broken and spidermonkey never gets a proper return value which results in some nasty unmanaged exceptions.

I have yet to see any StackOverflowExceptions occur that weren't my own fault. Spidermonkey does have a guard against long running operations / loops it's called the operation timeout. SMScript has a method to set this it is SetOpertationTimeout(milliseconds). If you know of the BranchCallback from previous spidermonkey versions it is deprecated in 1.8.5 and thusly they recommend using the operation timeout.

By default, when you dispose of a script in smnet it will not force a garbage collection unless you specify that it should do so. If you notice that memory usage stays somewhat high when you dispose of a script, or you do not expect to create / destroy scripts very often I would try using:
RuntimeOptions.ForceGCOnContextDestroy in the constructor for SMRuntime (They are bitwise options and can be combined).

Mar 6, 2012 at 12:25 AM
Edited Mar 6, 2012 at 2:48 AM

Thank you for the provided informations. I will combine the js-engine with an c# to js compiler, it looks like this:

http://i40.tinypic.com/x6k389.png

the app above only for testing of course. I will integrate them in my community service. The c# to js itelf is commercial, but free for less than 2.500 lines of c# code(sharpkit).

My community members are able to write in "c#" her extensions. When you are asking, why i not using c# directly: it has a lot of technical reasons. For example stackoverflow's can crash the entire serverhost. And the problem with appdomains and the serializazion of objects. And embedding a custom compiled into the host will use lots of memory after some compilations and it's too dangerous, for example, with reflection, he can get control over the host(when in same appdomain). And there's no c# interpreter (no good one). The best one are v8 and spidermonkey, my decision is for spidermonkey.

I tried first V8, but the api seems to be "too" c++ near. For example, it makes uses of the native c++ heap, it's hard to get control in an clr-environment. And the documentation seems not to bee good. But you should know, i have "no" knowledges in c++. And the onliest(not onliest, but the best "v8" wrapper, --> http://javascriptdotnet.codeplex.com/discussions/347130 ) is "very" basic. And it seems, it's written more abstract than spidermonkeydotnet wrapper. this is maybe, the v8 api is more abstract, too. But maybe i'm wrong, i'm not a c++ developer. I was able to compile original v8 sources in 12 hours, the spidermonkey in "only" 6 hours --> lack of knowledge.

It seems, you oversee everytime my question, and i will now ask (for a last time ;) ): Are you interested in my compiled x64 binaries of nspr4.dll/lib and moz185.dll/lib ?

Greetings,
Sebastian

Mar 6, 2012 at 11:01 PM
Edited Mar 6, 2012 at 11:02 PM

I wouldn't worry too much about sending me the x64 binaries. I can compile them on my own (if necessary). I updated the SVN repository again this afternoon to include a couple bug fixes, along with the added features. You can find the SVN repo here.