Thanks for your answer but unfortunately the problem is deeper than I though.
I think that it is related to the way I call back javascript.
You can find the related class attached with this email. Ivy calls back the OnMessage method that just
initialises the arguments to be given to the javascript method (stored
in m_scriptCb) and set the timer to be used by the main thread as you suggested. The
calling is done in the fired() methods.
Now e.g. if I have a page that contains :
<img id="test" src="..." />
When I am calling back and I try to modify it through document.getElementById("test") I get an
exception (msg: null value) but modifying its properties could yet work.
I have found that defining a global variable in javascript to keep the
result of document.getElementById("test") solve the problem of the exception but the layout may not be updated (depending on whether the
image is in a div or not ...).
I am really at a loss to find out the common denominator between the
different bugs. I don't think it is a race condition as I have done simple testing with a unique call from Ivy.
If someone has an idea or a better way to do the calling, I am ready to test and change the class.
Thanks,
Julien
If you create a WebCore timer with an timeout of 0 that should allow
you to perform a reasonably low latency action on the main thread.
--Oliver
On 10/08/2007, at 10:41 AM, Geoffrey Garen wrote:
> WebKit is not thread-safe. If you want to perform external
> processing on a secondary thread, that's OK, but any calls into the
> DOM will have to happen on the main thread.
>
> Geoff
>
> On Aug 10, 2007, at 3:00 AM, Julien Chaffraix wrote:
>
>> Hi all,
>>
>> I am trying to make a wrapper in C++ for the Ivy protocol for OWB
>> (I think it could work on Webkit even though I have not tested)
>> that could world entirely in javascript. Ivy is a light-weigh
>> publish/subscribe protocol. It is based on callback functions that
>> you call when a regExp is seen on the bus.
>>
>> My main problem is that the thread that calls back functions is
>> the thread that handles incoming transmissions, that is not one of
>> Webkit threads.
>>
>> As my problem seems close to what is done in XMLHttpRequest, I
>> have tried mecanisms used by that class and particularly reusing
>> the code from JSAbstractEventListener::handleEvent to call my
>> object. The callback seems to work but developing a javascript
>> application on top of that lead me to discover that some part of
>> javascript are not working : for example, accessing some (not all)
>> element with document.getElementById("...") does return "null" in
>> the callback (but works in the Webkit threads) even though I could
>> access it directly in C++ through Document::getElementById.
>>
>> I do not know much about what I have done wrong but I am eager to
>> do the necessary debugging and testing.
>>
>> Maybe also my method is not the best so if someone has a better
>> idea, he is more than welcome.
>>
>> Thanks,
>>
>> Julien
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev