| iMatix home page|
| << | < | > | >>
This section notes constraints that we've come across on various systems. This is not meant to be a complete list of all possible problems.
SMTSOCK uses the select() call to wait for socket events. On UNIX systems, select() returns when the process receives a signal. We use this fact to implement the process timer, SMTTIME, in an application that may also be doing socket i/o.
Under Windows 95, however, the select() call does not unblock when a signal is sent. The winsock call WSACancelBlockingCall() is meant to unblock the select() call. This does not work under Windows 95, at least. (WSAIsBlocking() always reports FALSE.)
The consequence of this is that the timeout specified in the select() call makes a difference to the way that the timer work. If we use a 1-second timeout, for instance, we find that timer events are also limited to a resolution of 1 second. This makes it difficult to use timer events for real-time work in socket based applications.
This appears to be a bug in the Windows 95 winsock.dll; it may also affect Windows NT.
Our solution is to use WSACancelBlockingCall() in any case, should the winsock.dll support it correctly. Secondly, under Windows, we reduce the select() timeout from 1 second to 1/5th of a second. On other systems - UNIX, OS/2 - we use 1 second, so that the application uses minimal system resources.
|| << | < | > | >>||Copyright © 1996-99 iMatix Corporation|