Le Dimanche 11 Mai 2003 21:08, Ashley Winters a écrit :
> --- Germain Garand <germain@ebooksfrance.org> wrote:
> > That's not possible now though, since PerlQt isn't thread safe at
> > all.
> > I'll dig into that for the next release, it looks interesting.
>
> Ugh. Yes, PerlQt is not thread-safe. In order to acheive thread-safety,
> we can't keep any Perl SV* type variables in a global C variable.
>

Oh, OK, now I understand why I had all those funny "attempt to free 
non-existing shared string" errors in the global object hash :-]

> When a Perl thread is spawned, it clones all the variables into
> separate interpreters, and performs draconian global interpreter
> locking upon accessing anything shared between threads. Therefore, any
> Perl variables PerlQt uses would have to be stored within the Perl
> interpreter, and retrieved from Perl-space when used.

In my last attempt I had it barely working (with the above errors reports) by 
just locking the XS autoload. I believe just moving the object hash into Perl 
space and a few more locks would be enough.
Sure, locking autoload is quite a "critical path", but anyway, I'd think the 
main use would be to fire several ithreads doing non-qt things, which would 
communicate with the main GUI thread via message passing, so that's not a big 
deal...

I've been busy coding the PerlQt plugin for the Designer (mainly fighting to 
death with buggy half-baked interfaces no body seems to have ever used nor 
tested yet), so I didn't have time to test that.

>
> The better answer is: use Qt thread-safe datastructures everywhere!
> Yay!
>
> Does a QThread have to be created before the Qt datastructures start
> locking themselves?
>

I don't think so. It looks totally independent.
From the documentation, when thread support is enabled, a few methods are 
reentrant or threadsafe (like qApp()->postEvent() ).

<quote>
    Calling a thread-safe function simultaneously with the same data is safe,
    since all access to the shared data are serialized. 
</quote>

One can also explicitly lock the global qApp() mutex to perform simple GUI 
operations across threads.

But I know very little about threads.
Germain

P.S: I just checked your GCC::TranslationUnit.
It's always a great experience to read good code, but when it's even 
*thoroughly commented* good code, it's just bliss! 

I tried to XMLout( 
GCC::TranslationUnit::Parser->parsefile("foo.tu")->root->xml )
and was ... awed 8)


> Ashley Winters
>
> __________________________________
> Do you Yahoo!?
> The New Yahoo! Search - Faster. Easier. Bingo.
> http://search.yahoo.com
> _______________________________________________
> Kde-perl mailing list
> Kde-perl@mail.kde.org
> http://mail.kde.org/mailman/listinfo/kde-perl

_______________________________________________
Kde-perl mailing list
Kde-perl@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-perl