octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Thread-safety issues in QtHandles


From: Michael Goffioul
Subject: Re: Thread-safety issues in QtHandles
Date: Wed, 2 Nov 2011 23:17:28 +0000

On Mon, Oct 31, 2011 at 5:46 PM, Michael Goffioul
<address@hidden> wrote:
>> Note that the change you are proposing will affect more than just
>> code in Octave.  There are some classes in Octave Forge that will be
>> affected because they also use the count member directly.  I've never
>> particularly liked the fact that classes had to increment count (or
>> ask the constructor to increment it), so this may have been bad
>> design.  I'm not opposed to fixing it, but there will be some
>> breakage if we delete the count member from the octave_value class.
>
> I know that this will basically break everything... Though there have
> also been significant changes in 3.4 release that broke some
> octave-forge package.
>
> Note that my goal is to provide make octave more thread-safe and solve
> the issues I have in QtHandles. Once I've completed the changes, I'll
> test them in QtHandles and check whether the issues are actually
> solved. If there are not, there will probably be no point in
> integrating those changes in octave.

I've completed a first run of changes. The draft patch is in
attachment (please note: "draft" as in not finalized). It's quite big,
but it's actually a bunch of repetitive changes. However, when I run
the test suite, I get a crash at the end in the cleanup_and_exit
function. I narrowed down the problem to: run tests in
scripts/sparse/bicg.m, then call "clear -f".

I'm pretty sure this is due to the way octave_base_value* (or derived
classes) are stored in the symbol table and/or the parse tree. My
impression is that more than one octave_value objects are built using
the same internal octave_base_value* pointer. This results in multiple
shared_ptr objects pointing to the same memory location, hence
multiple delete calls. However, that part of the code is quite complex
(and new to me) and I couldn't pinpoint the cause of the problem. It
only happens when using the test function; if I copy the test code
from bicg.m into a script and run it, it works fine.

Any hint would be appreciated.

Michael.

Attachment: thread_safe_refcount.bz2
Description: BZip2 compressed data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]