receiveTimeout minimum reasonable timeout value?

[Charles Hixson via Digitalmars-d-learn]

Duration can be specified in nanoseconds, but does it make any sense 
to have a value of 1 nanosecond?  0?

My desire is to check whether a message is in the queue, and then 
either move it local to the thread, or continue, depending.

Secondarily, is there much overhead in calling receiveTimeout 
frequently?  It would minimize the storage in the Tid mailbox, but at the 
cost of requiring more local storage.  As I can only receive one 
message (if there is one) at a time anyway, it's not clear that I would 
save much by calling it only once/iteration.

The current design is that I have an array of classes to tell to process 
themselves and I have a local AA of messages, with id#s that say which 
class instance they are intended for.  I could either loop through the 
array, and then loop receiving messages, or I could receive messages 
in between processing each instance.  The messages received may be 
intended for any instance in the thread, so they get stacked in an AA of 
the form:
Msg[uint64_t][] msg;
Msg is immutable and contains both from and to identifiers, among 
other things not all of which have been decided.  (Well, it's a struct of 
which all fields are immutable, so I presume the struct counts as 
immutable, though I haven't yet tested it.  I may need to redefine it, but 
it's intended as immutable.)  And the only thing passed to receive is a 
Msg (or a couple of control values in an enum).

As an aside, is it better to have more threads than processors?  TDPL 
seems equivocal about this.