2008/4/8, Arjen de Korte <[EMAIL PROTECTED]>: > > right. there are many things that we talked about with Russell (a long > > time ago) that are still to be done. And I'm pleased to see that > > you're working on it ;-) > > > The most urgent problem, is probably blocking on connect() that was > troubling for a while in the 'netxml-ups' driver, but turns out to be just > as big a problem in the upsclient library. > > Until recently, we have worked around blocking on read() and write() in > some clients (most notably, 'upsmon') by prepending alarm() calls to the > library functions. Now that the read/write functions to the library no > longer use blocking I/O, these can (and will) be removed. > > Surprisingly, we never used this mechanism on upscli_connect(), which > can/will block just like the read/write actions did. Until recently, I > wasn't even aware that this might be (and actually is) a problem. Should > we attempt to solve this in nut-2.2.2 or (preferably) leave this for > nut-2.4.0 (so that we have a bit more time to see if the changes are > portable)?
I don't want to retain much more 2.2.2 since it should have already been released for some time. so, leaving this for 2.4 is fair enough Arnaud -- Linux / Unix Expert R&D - MGE Office Protection Systems - http://www.mgeops.com Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/ Debian Developer - http://people.debian.org/~aquette/ Free Software Developer - http://arnaud.quette.free.fr/ _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
