Is it somehow possible to declare the $arduino object as shared, so the garba collection avoids it?

Not directly no. Each thread gets its own copy (actually not a fully copy, but a proxy to the real thing) of each shared variable; and that proxy is local to the thread and must be destroyed before the thread ends. In many cases, the appropriate action is to do nothing in the destroy unless this is the last copy of the handle.

In theory, there is a mechanism whereby module authors can make their modules thread-aware and possible thread-safe, by taking control of the cloning process by defining sub CLONE{ .. } in their packages; but the mechanism is barely described and I've never seen an example of anyone using it; so I cannot comment further on it. Besides which you'd either have to get the author of D::SP interested; or make your own changes.

Just saw your update:

So the idea is to create a new Device::SerialPort class which inherits the original class and overrides the destructor, right?

That is the essence of the first of the two possibilities I offered. And you could go the full subclassing route if that's your thing. Personally, I wouldn't.

I'd just inject my override directly into the D::SP namespace. Ie. At the top of your program somewhere after you've used Device::SerialPort, define a subroutine:

sub Device::SerialPort::DESTROY {
    my $self = shift;
    return unless (defined $self->{NAME});
    if ($self->{"_DEBUG"}) {
        carp "Destroying $self->{NAME}";
    }
    #$self->close;
}
[download]

You'll get a "subroutine redefined" warning -- which you can disable -- but the affect will be the same as 'doing it properly' without the hassle.

Simply commenting out the #$self->close; may be enough. If not, then you will either have to investigate why not; or try my second suggestion.

Don't forget to call close() in the same thread as you created the USB connection before finishing.

Ok, tried it properly with a new class which inherits DEVICE::SerialPort and the direct way above. Both have the same effect:


*** Error in `/usr/bin/perl': corrupted double-linked list: 0x00000000
+0173d840 ***
[download]

or

Segmentation fault (core dumped)
[download]


The error messages differ on the crashes. Seems the garbage collection still wants to clean up something and messes it up.

Found this. Sadly i don't understand it and don't know if this may be of any help.

Tomorrow i'll try your second suggestion. Thx alot so far.

Both have the same effect: *** Error in `/usr/bin/perl': corrupted double-linked list: 0x000000000173d840 *** or Segmentation fault (core dumped)

It was a long shot at best. As I don't do *nix, there is no way for me to investigate those errors further. They do not seem to originate in the Device::SerialPort code.

Found this. Sadly i don't understand it and don't know if this may be of any help.

No. It won't help.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.