2011/10/6 Stephan Beal <[email protected]>

> On Thu, Oct 6, 2011 at 5:18 PM, Ondřej Žára <[email protected]> wrote:
>
>> Okay, will try this: link v8cgi with libv8.a; link my modules with
>> libv8.so. V8 symbols will be available at runtime so the modules will be
>> happy; libv8.a will be linked just to main binary. Sounds reasonable; will
>> let you know about the outcome.
>>
>
> i _think_ that runs the risk of the problem you and i discussed a few days
> ago - a "split brain" (as it's known in clustering jargon). Some of v8's
> file-local static (not exported) internals might be in the static bits and
> some might be allocated again in the DLL. Might. Maybe.
>
>
The main idea here was that the whole V8 will be loaded into memory only
once, because it will be linked only once - as a static library to v8cgi.
All other modules will be linked to shared V8, which will not be actually
used - because all of the symbols will be available from v8cgi binary.

However, this approach does not seem to work: there is no segfault, but the
app still crashes. I will investigate this in more detail later, but it is
pretty straightforward that my initial impression of this setup was way too
optimistic.

O.



>
>>
>>> Ideally you shouldn't have to static link with libv8.a at all.  I bet
>>> there are gcc/ld flags that would allow all to be .so.
>>>
>>>
>> Yes, the shared solution works flawlessly. I am just trying an
>> alternative, suggested by one of my users...
>>
>
> But of course i've been known to be wrong ;).
>
> --
> ----- stephan beal
> http://wanderinghorse.net/home/stephan/
>
> --
> v8-users mailing list
> [email protected]
> http://groups.google.com/group/v8-users
>

-- 
v8-users mailing list
[email protected]
http://groups.google.com/group/v8-users

Reply via email to