SpiderMonkey: multithreading on exotic OS

[Antonidze]

I'm embedding JavaScript functionality in large project on VxWorks OS.
Besides all i should supply working with JS by several simultaneous threads.
So, as written in SpiderMonkey documentation, i should compile my code with
JS_THREADSAFE option. But VxWorks OS is not supported by NSPR :(
Does porting NSPR to VxWorks platform is my only way or i may try
"externally" defend library (for example, lock all JS API calls in global
critical section)?

Thanks
--
View this message in context: http://www.nabble.com/SpiderMonkey%3A-multithreading-on-exotic-OS-t1272145.html#a3376741
Sent from the Mozilla - JavaScript Engine forum at Nabble.com.

[Brendan Eich]

Antonidze wrote:
> I'm embedding JavaScript functionality in large project on VxWorks OS.
> Besides all i should supply working with JS by several simultaneous threads.
> So, as written in SpiderMonkey documentation, i should compile my code with
> JS_THREADSAFE option. But VxWorks OS is not supported by NSPR :(
> Does porting NSPR to VxWorks platform is my only way or i may try
> "externally" defend library (for example, lock all JS API calls in global
> critical section)?

You can't do that, in general. If you could, it would be at a terrible
performance cost, but I believe it just won't work ar all, if you have
any objects shared among threads.

If you share nothing among threads, then you could have a runtime as
well as a context per thread, but you would still need JS_THREADSAFE and
some NSPR locking API emulation.

So that brings me to the punchline: obvoiusly SpiderMonkey depends on
about a dozen PR_* NSPR entry points. You don't need to port NSPR to
"port" or emulate these. In fact people (Mike Moening at least) have
done this for Win32 already.

/be

[sha...@shantirao.com]

On 3/13/2006 4:27 AM, Antonidze wrote:

> I'm embedding JavaScript functionality in large project on VxWorks OS.
> Besides all i should supply working with JS by several simultaneous threads.
> So, as written in SpiderMonkey documentation, i should compile my code with
> JS_THREADSAFE option. But VxWorks OS is not supported by NSPR :(
> Does porting NSPR to VxWorks platform is my only way or i may try
> "externally" defend library (for example, lock all JS API calls in global
> critical section)?
>
> Thanks

You're going to regret this. A couple of things to consider:

1. Don't run JS in real time. SpiderMonkey does a whole lot of memory
allocation.
2. Schedule a higher priority thread to do garbage collection for SM.
3. Your computer needs to have a floating point unit, or jsmath.c won't
compile.
4. Call the nice people at Wind River (you did buy a support contract,
right) and ask for help.

Shanti

[Antonidze]

> If you share nothing among threads, then you could have a runtime as
> well as a context per thread, but you would still need JS_THREADSAFE and
> some NSPR locking API emulation.

Brendan, why? If i'll guarantee that all JS API functions will be called
sequentally (but from different threads) - why i still need JS_THREADSAFE?
Does there any difference to SM if two API functions will be called from
single thread one after one or they will be called from two threads, but
also one after one?

> You don't need to port NSPR to "port" or emulate these.

Please explain a little bit more. In VxWorks i have it's native
synchronization API, unsupported by NSPR. How can i get NSPR functionality
without porting it VxWorks?

Thanks

--
View this message in context: http://www.nabble.com/SpiderMonkey%3A-multithreading-on-exotic-OS-t1272145.html#a3391519

[Brendan Eich]

Antonidze wrote:
>>If you share nothing among threads, then you could have a runtime as
>>well as a context per thread, but you would still need JS_THREADSAFE and
>>some NSPR locking API emulation.
>
>
> Brendan, why? If i'll guarantee that all JS API functions will be called
> sequentally (but from different threads) - why i still need JS_THREADSAFE?

Because there are shared global variables, due to ancient API contracts
that we prefer not to break. Some recent work by Igor Bukanov may
remove some of these dependencies, but not all.

>>You don't need to port NSPR to "port" or emulate these.
>
> Please explain a little bit more. In VxWorks i have it's native
> synchronization API, unsupported by NSPR. How can i get NSPR functionality
> without porting it VxWorks?

I proposed implementing PR_NewLock/PR_DestroyLock/PR_Lock/PR_Unlock and
the related functions for CondVars, and the few other PR_* entry points
from NSPR that are used by SpiderMonkey #ifdef JS_THREADSAFE, in as
direct a way as you can.

This isn't porting NSPR, so much as implementing a handful of its APIs.

/be

[Mike Moening]

Antonidze,

Shoot me an email and I'll share my "miniNSPR" code with you.
I'm sure you'll find it way easier to port than the full NSPR.
The "miniNSPR" can be compiled as a static library since it doesn't attach
itself to your threads and does not create PRThread objects.
Its also about 20-30% faster than the regular NSPR when testing high volumes
of threads (at least in my case it was)

Mike M.

"Brendan Eich" <bre...@meer.net> wrote in message
news:4415CB03...@meer.net...

[Steve Parkinson]

Sounds great!

Is this hosted anywhere? I'm sure lots of people would like to take a
look at it.

Steve

[Mike Moening]

It's not hosted because I didn't know where to put it. I was hoping to get
it hosted in mozilla somewere near the spidermonkey project.
I ran into the same roadblock that every multi-threaded spidermonkey user
does: "What is NSPR and why can't I use it as a static lib again???"

I call it miniNSPR for lack of a better name.
It's very similar to the existing NSPR with regards to file names (I wish it
wasn't) and C structures, except its been stripped down to the bare bones to
contain only what spidermonkey needs to run safely in multi-threaded land.

Its not been ported to linux or other OS's yet (just Win32). I doubt
however that would be very hard to do.
You will have to roll your own compiler specific project or make file for
anything other than windows.
Other than that you just need to stick in your own platform specific
syncronization primitives (I could probably do that if somebody poked a
stick at me)

Now that I have it working sollid I'd like to refactor it and clean out the
old NSPR style of coding.

Interested in helping? I"m sure we could port it quick with a little help.

"Steve Parkinson" <s-p-a-r...@redhat.com> wrote in message
news:44232B78...@redhat.com...

[Brendan Eich]

Mike Moening wrote:
> It's not hosted because I didn't know where to put it. I was hoping to get
> it hosted in mozilla somewere near the spidermonkey project.
> I ran into the same roadblock that every multi-threaded spidermonkey user
> does: "What is NSPR and why can't I use it as a static lib again???"

There used to be a mininspr under js/src, you can still see it if you
cvs up with -d but not -P.

File a bug and attach your code! This time a zip is ok ;-).

/be

[Mike Moening]

That old miniNSPR didn't have any thread sycronization stuff in it. So it
wasn't very usefull. OK, I'll fill a bug and upload the code.

"Brendan Eich" <bre...@meer.net> wrote in message

news:Y-mdnQ63So3QG77Z...@mozilla.org...

[Peter Wilson]

Hi Mike,
did you file a bug and attach your code? I couldn't see it in bugzilla.

I'd really like to take a look - I've *started* incorporating NSRP into Whitebeam several times and each time given up. Mainly due to time
constraints. It's a while since I last tried but I seem to remember some of the problems being in SpiderMonkey expecting the NSPR code being in a
specific directory relative to itself. Required the Mozilla source tree I think.

Pete
--
Whitebeam (http://www.whitebeam.org
-----