What the hell does select() do?

Warning – This could be wrong

And no guarantees, either. I’m thinking out loud, exposing my ignorance.

Perhaps I should read up on what select() is intended to do: If none of the fd’s File Descriptors (which may be threads) has anything to do, then the process is blocked until one of them (which may be a thread) has data available to read/write/exception (aka error or timeout) and then number of fd’s passed in to select that wouldn’t block on a read/write op is returned. Think read for illustration purposes.

I prefer not to know the gritty details of how that happens when my mouse moves, but that fd would have data that is ready to read so if select was blocked waiting for mouse movements or keyboard clicks or TCP-IP packet arrival it would unblock the process and report to the select() caller that one of the watched fd’s is ready to be read (for illustration).

Thats what the shoes_app_g_poll does. It takes a set of Gtk fd’s (read set, write set, exception set) and if none of them has anything to do it tells the OS to not run me until something happens on those fd’s. So it waits for a mouse click or a key-press. Then the caller has to sort out which event happened and call the Shoes code needed to respond to it. There’s a lot code to make that translation from mouse click to executing the { block} attached to a button in your script. That works. It has worked for years and years in Linux. Native Windows and OSX are slightly different but they do the same thing: call some Shoes code. Thats the 10,000ft view.

Now we need to look at what Shoes/GTK/Windows does instead of the Shoes/GTK/Linux that just works. For Windows, Shoes/GTK only works for a few minutes until Windows in it’s mommy loving wisdom decides the application is hung and “not responding”. It also use 100% of 1 cpu core doing nothing which is anti-social. Even though you might thing its working just fine for a while, Mommy thinks its hung.

If you had read all the documentation and source code then you’d know that GTK/Windows file descriptors aren’t really like Linux fd’s. And you know the Ruby Windows has its own stdio and threading implementations. I didn’t understand that either. As it turns out Ruby/Windows file descriptors (fd) are not really like Linux fd’s either, And they aren’t like GTK/Windows fd’s because that would be too simple. For extra fun they both want to be opaque so programmers don’t have to know the details. Gtk does document it. Ruby? not so much (aka nada)

We’re flying just above ground now, heading for the marsh at the end of the landing strip unless we can get lift. Perhaps you’re thinking that I can’t match Windows/Gtk fd’s to Ruby’s fd (neither of which is like Linux fd’s except in opaqueness). I’m not sure I can move between them either. I’m not sure I want to fix anything for Windows.

Leave a Reply

Your email address will not be published. Required fields are marked *