Ben Sandee wrote:

> On Thu, Nov 6, 2008 at 9:11 PM, David Schwartz


>> > 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.


__________________________________________________ ____________________
OpenSSL Project
User Support Mailing List
Automated List Manager