> Well, that's the Unix interface you. I you don't like it, why don't you
> become a Windows programmer and try your hand at the Win32 interface? :-)
>
> Seriously, doing something different for /dev/random compared to all
> other read(2) calls is a bad idea; it will get people confused. The
> answer is whenever you call read(2), you must check the return values.
> People who don't are waiting to get themselves into a lot of trouble,
> particularly people who writing network programs. The number of people
> who assume that they can get an entire (variable-length) RPC packet by
> doing a single read() call astounds me. TCP doesn't provide message
> boundaries, never did and never will. The problem is that such program
> will work on a LAN, and then blow up when you try using them across the
> real Internet.
>
> Secondly, the number of times that you end up going into a kernel is
> relatively rare; I doubt you'd be able to notice a performance
> difference in the real world using a real-world program. As far as
> source/object code bloat, well, how much space does a while loop take?
> And I usyally write a helper function which takes care of the while
> loop, checks for errors, calls read again if EINTR is returned, etc.
Agree. I thought that en exhausted entropy pool gave less random numbers
on the next read. After having a look at the source I realized I was
taking nonsense.
> - Ted
Igmar
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
