in reply to Re^2: Problem with Threaded Socket Server
in thread Problem with Threaded Socket Server
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.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^4: Problem with Threaded Socket Server
by piece (Novice) on Aug 18, 2013 at 21:29 UTC | |
by BrowserUk (Patriarch) on Aug 18, 2013 at 21:45 UTC |