I belive it was an attempt to drop random sleeps, considered a waste of time.

From the "sleeps are bad" dept.

BTW, I've found the thread about the DNS issue.
The reporter also suggest to "sleep" (while the current code,
in case of DNS resolving lag, doesn't even select...)
http://marc.info/?l=gnash-dev&m=128289903628873

What was the reason for introducing select()?

`cause you replaced the fixed-time sleep with the select:
4006e6d610421d15a65e92019587512526583bf3

URL in submission is supposed to be http://cdn.optmd.com/V2/73952/203826/mor_13fifty_v1_728x90_cas.swf

STR:

trickle -d 1  gui/.libs/lt-gtk-gnash http://cdn.optmd.com/V2/73952/203826/mor_13fifty_v1_728x90_cas.swf

(Trickle is a bandwidth limiter. Alternatively, if you have a router utterly devoid of QoS, like mine, you can simply start an upload rather than run trickle.)

You'll notice that CPU rises to 100% on at least two cores and stays there for quite some time.

After some debugging I've pinned the issue down to fillCache() busy-looping when data is available continuously. In a low-bandwidth situation, data trickles in for a long time, leading to little to no time spent waiting in select(). With this SWF, a bunch of threads are started at the same time, exacerbating the problem.

Sandro suggests that this could be fixed by reintroducing a sleep removed by 4006e6d610421d15a65e92019587512526583bf3.