I thought about using poll, but it would require bulding and managing a resizing
array of pollfd structurers, where select uses a single fixed size fd_set object. This was the one case where select seemed a more natural fit.
You are correct that SerialService and SocketService probably could themselves be derived from a single base class, but unfortunately win32 support will make it impossible to use a single class for both; in win32, sockets are handled by integer descriptors and serial ports thru "handles", one can use select() for the socket, but uses wait on multiple object for handling the serial ports. For this reason, I kept the two seperate in the posix tree. This may also be true of other target platforms (such as OS/2, and BE/OS) that may be supported in the future.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I thought that possibly the win32 system would have some problems.
I would suggest that A win32 socketserialservice class actually spawn
2 threads and hence have a nice interface and not have to punish
Linux users for Win32's inability to mux sockets and serial ports properly !
Where would you like me to send the patch ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Essentially, SocketService and SerialService do
the same thing. It would be nice to merge these
into one class. ... using poll() of course !
I thought about using poll, but it would require bulding and managing a resizing
array of pollfd structurers, where select uses a single fixed size fd_set object. This was the one case where select seemed a more natural fit.
You are correct that SerialService and SocketService probably could themselves be derived from a single base class, but unfortunately win32 support will make it impossible to use a single class for both; in win32, sockets are handled by integer descriptors and serial ports thru "handles", one can use select() for the socket, but uses wait on multiple object for handling the serial ports. For this reason, I kept the two seperate in the posix tree. This may also be true of other target platforms (such as OS/2, and BE/OS) that may be supported in the future.
I thought that possibly the win32 system would have some problems.
I would suggest that A win32 socketserialservice class actually spawn
2 threads and hence have a nice interface and not have to punish
Linux users for Win32's inability to mux sockets and serial ports properly !
Where would you like me to send the patch ?