More than seven years after I initially started the backports.org project, it finally happened: backports.org moved to backports.debian.org! Alexander wrote an announcement including some technical details, the most important point from a users perspective is to update your sources.list entry to:deb http://backports.debian.org/debian-backports/ lenny-backports main contrib non-freeThanks a lot to all people who made it happen, especially Alexander Wirt and Jörg Jaspert!

Glen Mazza posted a review of the Camel in Action book on his blog, september, 2nd 2010.

The material is the latest MEAP edition of the book (the 8th update). Nevertheless the material contains all 14 chapters and in addition 3 appendixes. The final book will contain a few more appendixes and all the chapters will be revised to tighten up the language and improve the content. For example we will add more tips/hints for the new stuff we have since added into the Camel 2.5 release. We aim to cover Camel 2.5 with the book.

Manning is looking for people to review the final book, and if you are interested you can contact them by email at: mkt@manning.com

Image via Wikipedia

Two updates for Debian today.

I'm the upstream for psmisc and 22.13 finally got released, which also meant 22.13-1 Debian package got released too. There was some delay to it (see below why) but it is now out.  Unless you run a mips or superH architecture, there is not really any exciting changes, but should make it compile for those two architectures and then at least get the mips buildd underway so the versions all line up.

Secondly, gjay had two minor bug fixes and was updated.  If the analysis daemon kept playing music instead of looking at it or the vorbis files were not being recognised, then this new version will help there.  The mpg123 command line patch will be rolled into the upstream too.

I'm also working on getting gjay to work with the Exaile player.  If you want it to work with your player the easiest thing is to send me patches or code snippets that do the following:

• Detect your player is running
• Can give me the currently played song, preferably the filename of it. Exaile doesn't so I'll put it a kludge to guess it from title and artist
• Remotely send a playlist to your player and get the player to start

Last of all, my second son was born last week. It's back to those night feeds again and is probably why I've not written as much code as I normally would; but I wouldn't change that either.


<script defer="defer" src="http://static.zemanta.com/readside/loader.js" type="text/javascript"></script>

Module::Install has been through a long period of gradual stability over the last year, without any really dramatic improvements to the grammar or APIs.

With the more urgent "it doesn't work with blah" stuff mostly solved now, one of the big remaining issues is around error clarity and excessive magic.

For example, some random author that is trying to checkout a Catalyst project needs:

1. To have Module::Install installed.
2. To have Module::Install::Catalyst installed.

In the case of the former, you get the semi-cryptic but at least standard "Can't find inc/Module/Install.pm in @INC" message, so the error is resolvable.

But in the latter case, you're likely to get something like "Unknown command 'catalyst_ignore'", with no real obvious resolution mechanism.

I think this idea of automatic plugin discovery is starting to hit it's limits in terms of clarity.

And so I'd like to do something counter to my natural instincts here, and make M:I more verbose.

I'm thinking of something like the following for explicitly declaring the use of a non-core Module::Install extension.

use inc::Module::Install qw{ Catalyst XSUtil };

This would both allow M:I to error with a much more meaningful error when you don't have a plugin, and also prevent the loading of unused plugins which should prevent accidental plugin collisions (some of which I've seen occurring in the CPAN Testers machines).

Thoughts?

Over the past one or two months, there have been few interesting changes happening at Xerces-J XML Schema 1.1 implementation. I feel obliged to share these enhancements with the XML Schema community, and also with folks at Eclipse WTP (where we enhanced few "schema aware" components of PsychoPath XPath 2.0 engine, to support these recent Xerces enhancements -- I think we improved the design of typed values of XML element and attribute XDM nodes in PsychoPath XPath2 engine, in case the XDM node has a type annotation of kind simpleType, with varieties list or union).

Here's a summary of XML Schema 1.1 assertion changes that have recently been completed with Xerces (these are all lying on Xerces SVN repos at the moment), which are planned to be part of the Xerces-J 2.11.0 release, planned to take please during November 2010 time frame.

1. Xerces-J now has a complete implementation of XML Schema 1.1 conditional inclusion functionality. The Xerces-J 2.10.0 release had implementation of XML Schema 1.1 conditional inclusion vc:minVersion and vc:maxVersion attributes. Xerces-J now supports all of "conditional inclusion" attributes as specified by the XML Schema 1.1 spec. The "conditional inclusion" attributes that are now newly supported in Xerces-J are: vc:typeAvailable, vc:typeUnavailable, vc:facetAvailable and vc:facetUnavailable. All of XML Schema 1.1 built-in types and facets are now supported by Xerces-J (at Xerces SVN repos as of now) related to XML Schema 1.1 "conditional inclusion" components.

2. There are few interesting changes that have happened to Xerces-J XML Schema 1.1 assertions implementation as well, that are planned to be part of Xerces-J 2.11.0 release. Xerces now has an improved assertions evaluation processing on XML Schema (1.1) simple types, with varieties 'list' and 'union'.

2.1 Enhancements to assertions evaluation on simpleType -> list:

Here's an example of XML Schema 1.1 assertions on an xs:list schema component:
[XML Schema 1]
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:element name="Example" type="EXAMPLE_LIST" />

<xs:simpleType name="EXAMPLE_LIST">
<xs:list>
<xs:simpleType>
<xs:restriction base="xs:integer">
<xs:assertion test="$value mod 2 = 0" />
</xs:restriction>
</xs:simpleType>
</xs:list>
</xs:simpleType>

</xs:schema>

If an XML instance document has a structure something like following:
[XML 1]
<Example>1 2 3</Example>

And if this XML instance document ([XML 1]) is validated by the above XML schema ([XML Schema 1]), Xerces-J would report error messages like following (assuming the name of XML document was, test.xml):
[Error] test.xml:1:25: cvc-assertion.3.13.4.1: Assertion evaluation ('$value mod 2 = 0') for element 'Example' with type '#anonymous' did not succeed. Assertion failed for an xs:list member value '1'.
[Error] test.xml:1:25: cvc-assertion.3.13.4.1: Assertion evaluation ('$value mod 2 = 0') for element 'Example' with type '#anonymous' did not succeed. Assertion failed for an xs:list member value '3'.

An assertion must evaluate on every simpleType -> 'list' item (which is validated by the itemType of xs:list) in an XML instance document. Xerces now does this, and needed error messages are displayed in case of schema assertion failures.

2.2 Enhancements to assertions evaluation on simpleType -> union:

Here's an example of XML Schema 1.1 assertions on an xs:union schema component:
[XML Schema 2]
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:element name="Example">
<xs:simpleType>
<xs:union memberTypes="MYDATE xs:integer" />
</xs:simpleType>
</xs:element>

<xs:simpleType name="MYDATE">
<xs:restriction base="xs:date">
<xs:assertion test="$value lt current-date()" />
</xs:restriction>
</xs:simpleType>

</xs:schema>

If an XML instance document has a structure something like following:
[XML 2]
<Example>2010-12-05</Example>

And this XML instance document is validated by the schema document, [XML Schema 2] the following error message is displayed by Xerces:
[Error] temp.xml:1:30: cvc-assertion.union.3.13.4.1: Element 'Example' with value '2010-12-05' is not locally valid. One or more of the assertion facets on an element's schema type, with variety union, have failed.

Xerces tried to validate the atomic value '2010-12-05' both with schema types xs:integer and MYDATE. Since none of these types could successfully validate this atomic value, and an assertion failed in the process of these validation checks, the relevant assertion failure was reported by Xerces.

If the XML schema, [XML Schema 2] tries to validate the XML instance document:
<example>10</Example>

no validation failures are reported in this case, since the atomic value '10' conforms to the schema type xs:integer, which results in an overall validation success of the atomic value with an 'union' schema type.

I'm ending this blog post now. Stay tuned for more news :)

And I hope, that this post was useful.

Emdebian Grip 1.0.1 (based on Debian GNU/Linux 5.0.6) is now available.

Emdebian Grip is binary-compatible with Debian, providing smaller packages for use on embedded devices. Emdebian Grip selects a subset of Debian packages and removes documentation and other non-binary content without recompiling the source code. Currently, Emdebian Grip supports amd64, arm, armel, i386, mips, mipsel and powerpc in the stable distribution. ARM support will be dropped in the next stable release in favour of armel.

This is the first update of the stable distribution Emdebian Grip (based on Debian GNU/Linux 5.0), bringing Emdebian Grip up to date with Debian 5.0.6. This update mainly adds corrections for security problems to the stable release, along with a few adjustment to serious problems.

Please note that this update does not constitute a new version of Emdebian Grip 1.0 or Debian GNU/Linux 5.0 but only updates some of the packages included. Systems will upgrade to 1.0.1 via the Emdebian mirror after an installation.

For more details on the changes within Debian through 5.0.1, 5.0.2, 5.0.3, 5.0.4, 5.0.5 and now 5.0.6, see the Debian news website.

As well as updates to packages which already existed in Emdebian Grip 1.0, the update includes many new packages, including apache2, aspell and variants, and matchbox.

e.g. 822 packages were released for armel in Emdebian 1.0; this update increases that number to 1,297.

I recently released a little application I wrote for personal use. I am very scrupulous mantaining my music collections. I fancy having them in lossless formats, specially FLAC for storage and Apple Lossless for playback in iTunes. To achieve a decent level of tidiness, I wrote some Python code so I can organize the files and associated metadata tags right from the command line.

The app can be found in its project page here.

Please comments, forks, jokes, donations or awards welcome!

GNU Parallel 20100906 has been released. It is available for
download at: http://ftp.gnu.org/gnu/parallel/

New in this release:

• Using --shebang GNU Parallel can be used as the parser for a script. E.g: #!/usr/bin/parallel --shebang traceroute (followed by lines of hosts)

• First community generated bugfixes

• Alt Linux package of GNU Parallel. Thanks to Michael Shigorin <mike at altlinux dot org>

• Sunfreeware package of GNU Parallel. Thanks to Steven M. Christensen <sunfreeware at gmail.com>

• Untested CentOS, Fedora, Mandriva, RedHat, and SUSE packages available through OpenSUSE build service: https://build.opensuse.org/package/show?package=parallel&project=home%3Atange

• Review of GNU Parallel. Thanks to Andrew McFague amcfague at wgen dot net http://www.andrew-mcfague.com/linux/utilities-linux/commands-every-serious-nix-user-should-know/#parallel

• First 1000 views of the intro video http://www.youtube.com/watch?v=OpaiGYxkSuQ or at http://tinyogg.com/watch/TORaR/ and http://tinyogg.com/watch/hfxKj/

• sql - a small script to access sql bases from the command line which is a handy companion to parallel --colsep

About GNU Parallel

GNU Parallel is a shell tool for executing jobs in parallel using one
or more machines. A job is typically a single command or a small
script that has to be run for each of the lines in the input. The
typical input is a list of files, a list of hosts, a list of users, a
list of URLs, or a list of tables.

If you use xargs today you will find GNU Parallel very easy to use as
GNU Parallel is written to have the same options as xargs. If you
write loops in shell, you will find GNU Parallel may be able to
replace most of the loops and make them run faster by running several
jobs in parallel. If you use ppss or pexec you will find GNU Parallel
will often make the command easier to read.

GNU Parallel makes sure output from the commands is the same output as
you would get had you run the commands sequentially. This makes it
possible to use output from GNU Parallel as input for other programs.

You can find more about GNU Parallel at:
http://www.gnu.org/software/parallel/

Watch the intro video on http://www.youtube.com/watch?v=OpaiGYxkSuQ or
at http://tinyogg.com/watch/TORaR/ and http://tinyogg.com/watch/hfxKj/

I bet nobody expected this (I didn’t) – the next distro-branded version of stripes is for freeBSD. The freeBSD logo is quite pretty, but distorting it ruins it beyound recognition. For this reason, the wallpaper has much less depth than the previous ones.

One is the obligatory blue (not to say vanilla version) and the other one is redish)

KDE be free…

And here’s the first attempt of making a KDE-branded one… I’m not yet satisfied with it, this is only a preview.

This is the second time that I have pressed publish when I meant to press preview. The solution – I hope – is the “Are you sure ?” plugin. All it does is ask you are you sure when you press publish. Let’s see if it works. If you see this well then it didn’t.

Well it works

If you run wordpress then you can get your copy over at the dev-tips.com website.

Long ago I've set up a small but occasionally useful service on merkel: Debian Official Kernel Configuration files. It extracts and stores the configuration files from all kernel packages ever uploaded to the archive (does not seem to work particularly well with stuff uploaded to experimental though). Now that merkel is going away, this service is likely going to die. If you care about things like that, and would like to see it continue beyond merkel's demise, feel free to grab the script code and historical config files, and set it up elsewhere (it's not likely that I'm going to bother).

I was reading C++ books last month on my commute, and I would like to look at something different too. This month I am looking at reading Ruby books.

Lets say you are writing your new awesome web application in Node.js, because you know, Node.js is the new hotness and awesome.

Lets also say, your new Node.js web application does non-trivial things, and hits a limited backend resource. You can’t rewrite this backend system in the new hotness of async Node.js yet, so it can only handle 10 concurrent clients. This should be a very common situation unless you happen to be at a new startup and are green fielding your entire application stack. If thats your case, Lucky you! But for everyone else, you need to control the amount of concurrency that Node.js applies to your backend.

I am going to examine the simplest case of an HTTP server, which hits a backend resource, transforms it, and returns it to the client. Oh yeah, I mean a Reverse Proxy server; A Proxy server isn’t all that different from most application servers, taking client input and hitting different backends.  A proxy server just happens to hit HTTP most of the time, while an application server hits a database or another resource, but lets not get too deep into that. Node.js just happens to make writing proxy servers very easy, and relatively short, so I like using it as an example.

All of the source code for the examples can be found inside my node-examples repository on github.

Basic Reverse Proxy

Here is our simple application server in Node.js, it takes in a client request, and proxies it to http://nodejs.org/, server_nolimit.js:

var http = require('http'); var sys = require('sys'); var destination = "nodejs.org"; http.createServer(function(req, res) { var proxy = http.createClient(80, destination); var preq = proxy.request(req.method, req.url, req.headers); console.log(req.connection.remoteAddress +" "+ req.method +" "+req.url); preq.on('response', function(pres) { res.writeHead(pres.statusCode, pres.headers); sys.pump(pres, res); pres.on('end', function() { preq.end(); res.end(); }); }); req.on('data', function(chunk) { preq.write(chunk, 'binary'); }); req.on('end', function() { preq.end(); }); }).listen(8080);

Note, this is in no way a valid HTTP 1.1 Proxy server, it breaks all kinds of things in the RFC, but its just bad enough for demos to work. It takes a client request in, creates an outgoing HTTP client request, and uses sys.pump to transfer the data.

It is functional, and if you threw 1000 concurrent clients at it, it would want to open 1000 connections to nodejs.org. Poor nodejs.org!

Limiting Outgoing Connections

This might appear to be the simplest approach, keep a count of the active clients, and if we are over the limit, start queuing any new clients.

The problem comes in with how Node.js behaves; You will also need to buffer any incoming data while the request is queuing. You could try to call pause() on the stream, but this is only advisory, so streams can still trickle some data you need to buffer. This means our simple code of adding a counter, becomes complicated by extra buffering and work arounds for how Node’s HTTP streams work.

server_limit_clients.js implements this, it accepts the client request, and keeps a currentClients variable up to date with the number of active outgoing requests. When one request finishes, it starts processing the next one:

var http = require('http'); var sys = require('sys'); var destination = "nodejs.org"; var maxClients = 1; var currentClients = 0; var _pending = []; function process_pending() { if (_pending.length > 0) { var cb = _pending.shift(); currentClients++; cb(function() { currentClients--; process.nextTick(process_pending); }); } } function client_limit(cb, req, res) { if (currentClients < maxClients) { currentClients++; cb(function() { currentClients--; process.nextTick(process_pending); }, req, res); } else { console.log('Overloaded, queuing clients...'); _pending.push(cb); } } http.createServer(function(req, res) { var bufs = []; var done_buffering = false; client_limit(function(done){ var proxy = http.createClient(80, destination); var preq = proxy.request(req.method, req.url, req.headers); console.log(req.connection.remoteAddress +" "+ req.method +" "+req.url); preq.on('response', function(pres) { res.writeHead(pres.statusCode, pres.headers); sys.pump(pres, res); pres.on('end', function() { preq.end(); res.end(); done(); }); }); function finishreq() { bufs.forEach(function(buf){ preq.write(buf); }); preq.end(); } if (done_buffering) { finishreq(); } else { req.on('end', function() { finishreq(); }); } }); req.on('data', function(chunk) { var tbuf = new Buffer(chunk.length); chunk.copy(tbuf, 0, 0); bufs.push(tbuf); }); req.on('end', function() { done_buffering = true; }); }).listen(8080);

I have to say, ew! It just got too complicated. This buffering yourself stuff sucks. In addition, if you had 1000 clients connect, most clients would just see a wonderful spinning spinner on their browser, waiting for their turn to get an outgoing client.

Limiting by accepting less

If your Node.js application is deployed behind a load balancer of some kind, it might be a better idea to provide it with back pressure to your load balancer, so it sends your application less traffic. A simple way to achieve this is to stop listening for connections.

When a socket in TCP is set to listen for incoming connections, the kernel keeps a backlog of pending connections, so while this method isn't perfect, under high load it will quickly push back to your load balancer to stop sending your application traffic. One problem is that currently Node.js hard codes 128 connections in the TCP listener backlog, so if your desired concurrency level is very low, this method will not be very effective in applying back pressure.

In addition because of how Node.js' IOWatchers work, even if you tell it to stop listening, it will continue processing any sockets it has already called accept on, meaning that this method is very crude, and relatively inaccurate on having exactly X clients making backend requests.

server_limit_incoming.js implements this, it reads new client requests until there are too many inflight, then it calls an internal function on the server instance's watcher object, stop(). This stops libev from listening for new clients on that socket, it removes it from the event loop. Once we are back below the maximum clients, it calls start on the IOWatcher, which adds the listening socket back to the event loop:

var http = require('http'); var sys = require('sys'); var destination = "nodejs.org"; var port = 8080; var maxClients = 2; var currentClients = 0; var active = true; var hs = null; function activate() { if (!active && currentClients < maxClients) { hs.watcher.start(); active = true; } } hs = http.createServer(function(req, res) { var proxy = http.createClient(80, destination); var preq = proxy.request(req.method, req.url, req.headers); console.log(req.connection.remoteAddress +" "+ req.method +" "+req.url); preq.on('response', function(pres) { res.writeHead(pres.statusCode, pres.headers); sys.pump(pres, res); pres.on('end', function() { preq.end(); res.end(); currentClients--; activate(); }); }); req.on('data', function(chunk) { preq.write(chunk, 'binary'); }); req.on('end', function() { preq.end(); }); currentClients++; if (currentClients >= maxClients) { hs.watcher.stop(); active = false; } }); hs.listen(port);

Overall this approach of stop accepting new clients is far less code than the earlier limiting method, and it lets your load balancers do smarter things under high load, hopefully meaning you have extra capacity on another machine, rather than just accepting more clients on an already overloaded server. It does use some 'hacky' knowledge internals of how HTTP streams and IO Watchers work inside Node.js, and it is far less accurate in its counting. However, I believe that this method is probably one of the better ways to limit your concurrency inside Node.js.

After several years of slacking :) by everybody involved it finally happened: backports.org has become backports.debian.org. For that to happen several things had to get changed and streamlined, so please make sure to read this announcement to avoid too many surprises.
We are happy to welcome a new ftpmaster, Gerfried Fuchs (rhonda) joined our team.
The website [1] and the mirror moved to http://backports.debian.org/ and the archive is now available below debian-backports/. Even though we expect the old entries to continue to work for a while, you might still want to update your sources.list entry to:  deb http://backports.debian.org/debian-backports lenny-backports main contrib non-freeor one of the mirrors[2] that do carry the backports archive.
Moving backports master to a newer version of the debian archive kit (dak) brings support for dpkg version 3 packages, so from now on debian-backports will accept dpkg source 3.0 packages without changes.
The backports service still uses its own version of the keyring.  Therefore if you want to put packages onto backports you have to coordinate with the backports team to have your uploads accepted.  Please follow the procedure outlined in [2].  Support for Debian Maintainers (DM) is expected to follow soon, if you are interested in helping to test this (and get added to the keyring) please contact Jörg Jaspert <joerg@debian.org>.
While we were at it, the backports branch for squeeze has been added as a squeeze-backports suite, which enables the installer to add (maybe commented) entries for it on fresh installations.  For now uploads to it are disabled however, to be enabled after therelease, whenever it'll happen. This will be announced separately.
The origin and the label of the Archive changed to "Debian Backports" so if you used them for pinning you will have to modify your apt.preference configuration.  Please refer to [3] for more information. Additionally the archive is now signed by the standard ftpmaster signing key, currently the Lenny key.
Mirroring is now managed by the debian mirror team[4] so if you want to get an official debian-backports mirror get in touch with <mirrors@debian.org> or use the submit webform[4]. Make sure you use the ftpsync script from [5,6].
The mailinglists moved to lists.debian.org [7,8,9], the subscriptions have been moved to the new lists.
Hosting for the equipment that powers backports.debian.org is graciously provided by the Electrical and Computer Engineering department of the University of British Columbia in Canada[10].  Thanks.
We also would like to thank team(ix)[11] for providing a good home for this service for all these years.  As mentioned above backports.org will continue to remain functional as a mirror of the official repository from debian.org for a while.Thanks for your attention,the debian-backports ftpmasters (ftpmaster@backports.debian.org), Alexander Wirt, Gerfried Fuchs, Jörg Jaspert.
[1] http://backports.debian.org/[2] http://backports-master.debian.org/Mirrors/[2] http://backports.debian.org/Contribute/[3] http://backports.debian.org/Instructions/[3] http://www.debian.org/mirrors/ftpmirror[4] http://www.debian.org/mirrors/submit[5] http://ftp-master.debian.org/ftpsync.tar.gz[6] http://ftp-master.debian.org/git/archvsync.git/[7] http://lists.debian.org/debian-backports[8] http://lists.debian.org/debian-backports-announce[9] http://lists.debian.org/debian-backports-changes[10] http://www.ece.ubc.ca[11] http://www.teamix.net

While making a CSS layout for a client I had issues with transitions on WebKit-based browsers, I couldn’t make it renderize more than one transition at the same time with the short -webkit-transition, the line was:

-webkit-transition: background-color .25s linear, shadow .25s linear;

Doesn’t works on Safari 3 nor in Google Chrome 6 so I tried splitting out the lines to:

-webkit-transition-property: background-color, shadow; -webkit-transition-duration:.25s, .25s; -webkit-transition-timing-function: linear, linear;

And now it works! But it sucks, now I have to write three stupid lines instead of one for the same thing, something that works perfectly on Firefox4 and the draft says explicitly it should work, just:

-moz-transition: background-color .25s linear, shadow .25s linear;

Well, at least works…

It always pains me to explain these little identifier resolution traps:

#!/usr/bin/env python3   class Egg:   _next_id = 1   def __init__(self): self.id = self._next_id self._next_id += 1 assert Egg._next_id is self._next_id     if __name__ == '__main__': f = Egg()

Fails the assertion. It’s decomposing the assignment-update into its constituent tmp = self._next_id + 1; self._next_id = tmp components, but a programmer could reasonably expect a Lookup/Update hash map ADT operation to occur instead — get the slot by lookup, mutate the value found, and store back in an atomic sense, clobbering the class member with the updated value — but that’s not how it works.

This goes with the prototypal territory:

function Egg() { this.id = this.next_id; this.next_id += 1; assertEq(this.next_id, Egg.prototype.next_id); }   Egg.prototype.next_id = 1; var e = new Egg(); // Error: Assertion failed: got 2, expected 1

Fortunately, note that this behavior definitely has the semantics you want when you add inheritance to the mix. Is the self.viscosity that this class implementation is referring to a class member or an instance member in the base class?

#!/usr/bin/env python3   import sauce   class AwesomeSauce(sauce.Sauce):   def __init__(self): super().__init__() self.viscosity += 12 # Deca-viscoses per milliliter.

The answer is that you don’t care — it’s being rebound on the AwesomeSauce instance no matter what.

Moral of the story is to be mindful when using update operations on class members — if you want to rebind a class member within an instance method, you’ve got to use the class name instead of self.

• 473730
• 544338

The video here is a short (14:00 min) summary of the upgrade of himerus.com to Drupal 7, and also a quick look into the Gamma sub-theme, a new inclusion in the Drupal 7 branch of the Omega theme.

Thanks for taking the time to view it, the new site, and any feedback on the Gamma subtheme moving forward!!

read more

If you're working on a multi-platform project which does network communication you will end up thinking about replacing select(2) with poll(2) sooner or later. The problem with select are well known. poll(2) removes the limitations of select(2) and improves speed and features. The problem is that poll(2) isn't available on all platforms. This means you need a poll(2)-emulation or create wrappers around other similar poll() functions.

In libssh we use a poll(2)-emulation based on select for platforms which don't provide a poll(2) function like some Windows versions or UNIX systems.

Windows Vista or newer version provide a poll(2) like function called WSAPoll(). To be able to support this call which is faster the the poll(2)-emulation and allows to use more file descriptors we implemented a runtime detection for WSAPoll(). This means during initialization of the socket, we check if the functions can be found in the relevant library. If Windows doesn't provide it, we fallback to the poll(2)-emulation.

I took several month to get this working correctly on UNIX and Windows. This feature starts to work correctly with libssh 0.4.6 released today.