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; }
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.
In reply to Re^3: Problem with Threaded Socket Server
by BrowserUk
in thread Problem with Threaded Socket Server
by piece
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |