Re: threads, XSUB allocated memory, destructors, destruction

Andrew Torda <please@xxxxxxxxxxx> wrote:
> Greetings from the original poster
> > Thanks for taking the time to provide that example. That about wraps it
> > up for me ..... wonder how the op is getting on with this :-)
>
> I can tell you... Not very happy.
> Using CLONE_SKIP() does what it should. It stops you being
> destroy()ed. Unfortunately, "man perlmod" says your objects
> "will be copied as unblessed, undef values" and "if the
> child thread needs to make use of the objects, then a more
> sophisticated approach is needed.

Another possible way to prevent the children threads from trying to
free the data is to have the threads bail out with a POSIX::_exit.
I do this in forked processes all the time (where the goal is to prevent
the costs of cleaning up, which can be very great for large amounts of
data, especially with cow), but don't know how it will work in threads.


> OK.
> Maybe I should write my own CLONE(), although this is a bad
> idea. Perldoc Threads::shared says that "Currently CLONE is
> called with no parameters other than the invocant package
> name". This means you can't get to the address you need to do the
> copying.

You can, but you need to store that address (those addresses) somewhere
other than in the objects themselves (or you need to store the objects
themselves somewhere in the package).

> It is a catastrophically ugly approach to a large amount
> of data which should be shared since it is passed to threads for
> use in some calculations.

Exactly what kind of sharing are you doing? Is most the sharing read
only or does each thread need to be able to write such that the other
threads can see the changes?

If only the "master" thread need to write to this large amount of data,
and if you are using a unix-like system, then you could try forking
rather than threads. Perl may not know how to clone XSUB data, but the
kernel does know how to. And because of cow (copy on write), forked data
can live in the same RAM as the original until it starts getting changed.


>
> We are dealing with arrays of blessed objects. They should
> be shared between threads, but then one hits the problem
> that ""bless" is not supported on shared references. In other
> words, if one has a reference to a 2D array of blessed objects
> and says p $$coords[0][0], you get something like
> MyPtr=SCALAR(0x85efe8c). If you then mark it as shared,
> "share $coords", and try the print statement, you are bluntly
> told, "Invalid value for shared scalar at ...".

You should not get that from a print statement. That error occurs either
when you assign to a shared variable, or when you share a variable. Not
when you read from a variable.


Xho

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
.

Relevant Pages

  • Re: C++ vs. .net
    ... > in one of my C++ applications, I have quite a big amount of data ... > (linked lists, arrays, variables, ...) that I'd need to pass to a ...
    (microsoft.public.vc.language)
  • Re: Can you help me figure out why my macro is running slowly?
    ... then the first question I would have would be where is ... time variance in the amount of time it takes to run. ... Size the arrays to 1000 elements using ReDim. ... Write computed values to the workbook opened in step 3. ...
    (microsoft.public.excel.programming)
  • Re: Sum If using 2 criterias
    ... Then all 3 arrays are multiplied together and totaled for the final result. ... sheet summarizes the activity entered in the first tab. ... then return the "Amount" based on the criteria. ...
    (microsoft.public.excel.misc)
  • Re: please I need help on my java Applet
    ... > can input an amount to pay then it will display the remaining change. ... Tabs, long lines, redundant elements in arrays.. ... The SSCCE document warns you against all three. ...
    (comp.lang.java.programmer)