Ben Sandee wrote: > On Thu, Nov 6, 2008 at 9:11 PM, David Schwartz <[EMAIL PROTECTED]> wrote:
>> > There needs to be a call to fcntl(fd,F_SETFL,O_NONBLOCK) just after >> > the socket() call and error status check. >> That will just waste CPU. The code will spin in each loop >> "while (!success)" loop until it gets what it wants. It will >> still not return any time soon, but will do so at 100% CPU >> instead of 0% CPU. >>Unless I'm missing something. >It looks like the default error handler will catch EWOULDBLOCK and >"goto err", breaking out of the while() loop. If EWOULDBLOCK > happened during connect() then "0" is returned, If it happens > during read() or write() then -1 is returned. Is this an > important discrepancy? Well then the suggested change (making the socket non-blocking) will still break the code, just differently. If it's made non-blocking, it will never get any entropy, since it will never wait for the daemon to reply. What does it mean to ask a daemon a question and get an answer without blocking? Does it mean the daemon must reply in no time at all? How's that supposed to happen? If the intent was really that it never block, then it will have to return if it would otherwise have to block but keep the same socket around talking to the daemon. This means that sometimes it will have to return with a live connection to the daemon, which it may never have an oppurtunity to close. Sounds like the interface is badly thought out. Perhaps the best "reasonable compromise", short of changing the interface, is to set a limit (maybe 3 seconds or so) to how long RANG_egd can block (this would mean it will have to call 'poll' or the like). Yucky to do portably. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
