Some considerations about PRNGs Recently I read about pseudorandom generators and I have some observations:


My conlusion is a such that a secure implementation of a PRNG had to be blocking or returning an error code when it is too little entropy. If a PRNG does not do so it means that it cannot be secure- we cannot be sure that returned pseudorandom bits "comes" from true random bits (achieved with a sufficient entropy). Yes?
The presentation Understanding and Managing Entropy Usage points 
PRNG provided by OpenSSL does not reseed itself (a slide 32). Does it mean that in long-running application we have to reseed manually? Otherwise we don't have secure PRNG? If yes, how to reseed? Every minute? Every Hour? Every generated 1024 bytes? How to be sure that a seed was taken when entropy was sufficient?
If you know about books/chapters/blogs that covers my doubts let me know! 


Thanks in advance :)
Addressing some of your questions:-


  a secure implementation of a PRNG had to be blocking


A CSPRNG is the cryptographically secure version of a PRNG.  Given a good and unknown (to any attackers) seed, then the CSPRNG can run effectively for ever. ChaCha20 or something based around AES can generate oodlebytes of output.

It's a semantic distinction,but you could say that such CSPRNGs should block at initialisation. They should not output anything unless seeded correctly with adequate entropy.  And since unknown entropy is sometimes difficult to acquire, there might be a delay before the CSPRNG kicks off. Acquisition of 128 or 256 bits of unknown entropy can be lengthy for some implementations such as IoT devices without on board TRNGs.

Reseeding can be useful   however, especially in the case of a desktop computer /server.  Such devices allow other processes to execute alongside the CSPRNG. There are currently 263 running alongside my /dev/urandom device. Anyone of them could be spying on me.  Regular reseeding is an attempt to mitigate a potential compromise of the inner state of the CSPRNG.  If the RNG is running on an IoT fridge in your kitchen, such reseeding is not really necessary.


  ...how to reseed? Every minute? Every Hour? 


Well this is the trick.  It will depend on your environment.  The CSPRNG Fortuna uses a horribly convoluted, variable timed reseeding and pooling mechanism. A Quantis quantum key distribution system might re-key the conventional side every few minutes. This answer gives the default reseed rate of /dev/urandom as 1 minute.  I see no reason why an IoT wine cooler has to reseed at all between power cycles. I don't think that anyone can give you a meaningful reseed period. A piece of advice might be that if you have access to some form of TRNG, you might as well capitalise on it as often as possible.

Although   consider that in cryptography rather than simulation, the exact random stream is often closely related to a key and/or IV.   Simply swapping out the CSPRNG's inner state after a protocol has been established will suddenly break the session.  The protocol will have to be re-established. This adds complexity and computational /network overhead and also applies to OpenSSL. Your session would terminate.

As for further reading, this forum of course.  There's much debate under the entropy and CSPRNG tags.