Re: [FreeWRL-develop] Codebase port to c++?

[Ian S. A. <ia...@ae...>]

On 16/04/13 12:50 PM, doug sanden wrote:
> 
>> >>
>> >> Hey all, so spidermonkey-17 is released, which is going to be the last
>> >> spidermonkey that has a C API; after this it's C++ only.
>> >>
>> >> Should we port freewrl to C++ or freeze our compatibility to
>> >> spidermonkey-1.5 through 17 ?
>> >>
>> >
>> > What do you think Ian? Would you like to keep upgrading or would you
>> > prefer a freeze?
>> > -Doug
>> > The last time the freewrl C vs C++ issue came up, C won.
>> > I had done a test where I got freewrl to compile as C++. But then it was
>> > just C code that took longer to compile on my slow old machine, and had
>> > some awkward areas that would need a rewrite. We do have some C++
>> > at-the-margin: libs and plugins.
>> > I think there are ways to wrap a C++ library with a C interface, if
>> > necessary. But that could be more work for the main javascript
>> > maintainer - that's been you Ian - with unknown gain in functionality.
>> > My guess: freeze.
>> >


So something else that has just recently come to my attention --
spidermonkey (mozjs) will no longer work in a multithreaded environment
if it's the same "container" across multiple threads.

This definitely applies to us -- when the new container functionality
was introduced in 1.8.5, I did my best to be sure that we still only
worked within a single container, so that we weren't having to deal with
multiple root objects and all objects stayed in the same "scope".  Our
runtime *might* work fine as I believe your threads already handle
locking to take care of concurrent access of other shared memory, but i
can't say for sure.

Now, it could be that my (lack of) understanding of containers means
this isn't necessary; i'll look into it in the near future and see if I
can figure it out.

Anyways, the point being, we may need to freeze at the current version
of spidermonkey (1.8.5 official, or 1.8.7 unofficial) without that major
refactoring of our codebase.