On Thu, Dec 6, 2012 at 5:23 PM, Brandon Allbery allber...@gmail.com wro\
Both should be cdevs, not files, so they do not go through the normal
filesystem I/O pathway in the kernel and should support select()/poll().
(ls -l, the first character should be c instead of - indicating
On 9 December 2012 10:29, Leon Smith leon.p.sm...@gmail.com wrote:
On Thu, Dec 6, 2012 at 5:23 PM, Brandon Allbery allber...@gmail.com wro\
Both should be cdevs, not files, so they do not go through the normal
filesystem I/O pathway in the kernel and should support select()/poll().
(ls -l,
On 29 Nov 2012 12:27 PM, Leon Smith leon.p.sm...@gmail.com wrote:
Well, I took Bardur's suggestion and avoided all the complexities of
GHC's IO stack and simply used System.Posix.IO and Foreign.This appears
to work, but for better or worse, it is using blocking calls to the
read system
On Thu, Dec 6, 2012 at 3:24 PM, Tristan Seligmann
mithra...@mithrandi.netwrote:
On 29 Nov 2012 12:27 PM, Leon Smith leon.p.sm...@gmail.com wrote:
System.Posix.IO and Foreign.This appears to work, but for better or
worse, it is using blocking calls to the read system call and is not
Quoth Brandon Allbery allber...@gmail.com,
On Thu, Dec 6, 2012 at 3:24 PM, Tristan Seligmann
mithra...@mithrandi.netwrote:
On 29 Nov 2012 12:27 PM, Leon Smith leon.p.sm...@gmail.com wrote:
System.Posix.IO and Foreign.This appears to work, but for better or
worse, it is using blocking
On Thu, Dec 6, 2012 at 5:14 PM, Donn Cave d...@avvanta.com wrote:
While I guess /dev/urandom isn't supposed to block, so it would look
about the same to select(2) either way, /dev/random is select-able, true?
Both should be cdevs, not files, so they do not go through the normal
filesystem I/O
Well, I took Bardur's suggestion and avoided all the complexities of GHC's
IO stack and simply used System.Posix.IO and Foreign.This appears to
work, but for better or worse, it is using blocking calls to the read
system call and is not integrated with GHC's IO manager. This shouldn't
be
I have some code that reads (infrequently) small amounts of data from
/dev/urandom, and because this is pretty infrequent, I simply open the
handle and close it every time I need some random bytes.
The problem is that I recently discovered that, thanks to buffering within
GHC, I was actually
As an alternative, If there existed a Haskell package to give you fast
cryptographically secure random numbers or use the new Intel RDRAND
instruction (when available) would that interest you?
Also, what you are doing is identical to the entropy package on
hackage, which probably suffers from the
On 11/28/2012 08:38 PM, Leon Smith wrote:
I have some code that reads (infrequently) small amounts of data from
/dev/urandom, and because this is pretty infrequent, I simply open the
handle and close it every time I need some random bytes.
The problem is that I recently discovered that,
Quite possibly, entropy does seem to be a pretty lightweight dependency...
Though doesn't recent kernels use rdrand to seed /dev/urandom if it's
available? So /dev/urandom is the most portable source of random numbers
on unix systems, though rdrand does have the advantage of avoiding system
On 11/28/2012 09:31 PM, Leon Smith wrote:
Quite possibly, entropy does seem to be a pretty lightweight
dependency...
Though doesn't recent kernels use rdrand to seed /dev/urandom if it's
available? So /dev/urandom is the most portable source of random
numbers on unix systems, though
If you have rdrand, there is no need to build your own PRNG on top of
rdrand. RdRand already incorporates one so that it can produce random
numbers as fast as they can be requested, and this number is continuously
re-seeded with the on-chip entropy source.
It would be nice to have a little
13 matches
Mail list logo
