[Info-vax] "bad select 38" (OpenSSL on VMS)

johnwallace4 at yahoo.co.uk johnwallace4 at yahoo.co.uk
Mon Sep 19 08:38:25 EDT 2016


On Monday, 19 September 2016 13:07:18 UTC+1, Johnny Billquist  wrote:
> On 2016-09-17 14:07, Richard Levitte wrote:
> >
> > I agree with you there, partly...  VMS is not Unix, and when someone tries to have Unix as the holy standard, things are sure to get confusing.
> 
> Agree.
> 
> > That being said, the socket-only select() is lame.
> 
> Isn't that true of select() in Windows as well, or was that restriction 
> lifted after I last touched Windows (XP era). (Or do I remember wrong?)
> 
> 	Johnny

You don't remember wrong, and I don't think it's
changed.

>From memory, and after briefly trying to check the
world of Windows as it is today, calling select()
in a Win32 application will return the error
WSAENOTSOCK
if one of the specified fds ins anything other than
a socket. See e.g. (URL will wrap)
https://msdn.microsoft.com/en-gb/library/windows/desktop/ms740141(v=vs.85).aspx

But apparently it's only VMS that's got a problem
with this behaviour. Windows has other redeeming
features that make this behaviour a non-problem
on a Window box (presumably).

Those who care about proper POSIX-like (not MS-style)
select() behaviour on a Window box may wish to look
at Cygwin, who have this to say about their select()
implementation:

"Select

The UNIX select function is another call that does not map cleanly on top of the Win32 API. Much to our dismay, we discovered that the Win32 select in Winsock only worked on socket handles. Our implementation allows select to function normally when given different types of file descriptors (sockets, pipes, handles, and a custom /dev/windows Windows messages pseudo-device).

Upon entry into the select function, the first operation is to sort the file descriptors into the different types. There are then two cases to consider. The simple case is when at least one file descriptor is a type that is always known to be ready (such as a disk file). In that case, select returns immediately as soon as it has polled each of the other types to see if they are ready. The more complex case involves waiting for socket or pipe file descriptors to be ready. This is accomplished by the main thread suspending itself, after starting one thread for each type of file descriptor present. Each thread polls the file descriptors of its respective type with the appropriate Win32 API call. As soon as a thread identifies a ready descriptor, that thread signals the main thread to wake up. This case is now the same as the first one since we know at least one descriptor is ready. So select returns, after polling all of the file descriptors one last time."

from
https://cygwin.com/cygwin-ug-net/highlights.html

Have a lot of fun.



More information about the Info-vax mailing list