I'm relatively clueless when it comes to C++ so I may be missing the point but am wondering why SerialService::~SerialService() deletes its attached SerialPorts. Well, actually, I suppose it makes sense that one might want the Service class to get rid of the ports once it's finished Service-ing them, but it might be nice, at any rate, to be able to get a SerialPort detached (SerialService::Detach() has private visibility), thereby avoiding the Port's destruction, if one were so inclined
Just curious
And, to mitigate some of the extreme ingratitude I'm showing by looking the gift horse in the mouth--kudos and thanks to David S. <dyfet> and you other developers; this is great stuff
--buck
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Perhaps Detach should become a public or at least a protected member then. In my servers (like Bayonne) I tend to do static initialization of serviced ports at startup and bring them all down at shutdown, so I didn't much think of more dynamic scenario's.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It would be cool to have the option of Detach()-ing if possible, thanks; i suppose then that they'd also have to be re-Attach()-able also to be of any further use
<speculation class="uninformed">
It might actually be more natural to further abuse the SerialPort's friend status and sow some wrappers into the SerialPort class to detach and attach it, though, since the SerialPort seems, actually, to be more the object of Detach()-ment/Attach()-ment (and serialport->Detach() is less typing than serialservice->Detach(serialport))
</speculation>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
if the goal is to stick with the same SerialService, then, yes, that
makes perfect sense. if, for some inconceivable reason however, one had some SpecialSerialService (say it has a special onEvent() handler to ring the terminal bell, is initialized with a higher priority, or what have you) then it might conceivably be the case that one would want to shift SerialPorts around between various subtypes or instances of SerialService and not merely Detach() and Attach() to the same instance
this may all be academic, though; i'm not saying i would have any use for this
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Another use might be to "balance" a thread pool of serial service threads. Hence,
one might decide to add or delete devices, and the re-arrange the remaining
devices in a reoptimized manner based on a service pool list. So I can see another reason why "SerialPort"'s might want to become "detachable" or otherwise "mobile" in some fashion.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi
I'm relatively clueless when it comes to C++ so I may be missing the point but am wondering why SerialService::~SerialService() deletes its attached SerialPorts. Well, actually, I suppose it makes sense that one might want the Service class to get rid of the ports once it's finished Service-ing them, but it might be nice, at any rate, to be able to get a SerialPort detached (SerialService::Detach() has private visibility), thereby avoiding the Port's destruction, if one were so inclined
Just curious
And, to mitigate some of the extreme ingratitude I'm showing by looking the gift horse in the mouth--kudos and thanks to David S. <dyfet> and you other developers; this is great stuff
--buck
Perhaps Detach should become a public or at least a protected member then. In my servers (like Bayonne) I tend to do static initialization of serviced ports at startup and bring them all down at shutdown, so I didn't much think of more dynamic scenario's.
It would be cool to have the option of Detach()-ing if possible, thanks; i suppose then that they'd also have to be re-Attach()-able also to be of any further use
<speculation class="uninformed">
It might actually be more natural to further abuse the SerialPort's friend status and sow some wrappers into the SerialPort class to detach and attach it, though, since the SerialPort seems, actually, to be more the object of Detach()-ment/Attach()-ment (and serialport->Detach() is less typing than serialservice->Detach(serialport))
</speculation>
Silly thought - why bother Detaching when you can
setDetectPending( false ) and setDetectOutput( false ).
You will still get called on hangup (exactly once)
or timer expiry but you can manage that.
if the goal is to stick with the same SerialService, then, yes, that
makes perfect sense. if, for some inconceivable reason however, one had some SpecialSerialService (say it has a special onEvent() handler to ring the terminal bell, is initialized with a higher priority, or what have you) then it might conceivably be the case that one would want to shift SerialPorts around between various subtypes or instances of SerialService and not merely Detach() and Attach() to the same instance
this may all be academic, though; i'm not saying i would have any use for this
Another use might be to "balance" a thread pool of serial service threads. Hence,
one might decide to add or delete devices, and the re-arrange the remaining
devices in a reoptimized manner based on a service pool list. So I can see another reason why "SerialPort"'s might want to become "detachable" or otherwise "mobile" in some fashion.
David,
The more I hear you talk about pools of ports the more
I think this could be a base functionality in
SocketService and SerialService ...
Cheers
G