>> The general idea would be to still use UDP backend->stats but get rid
>> of
>> the pipe part (emulated by standard tcp sockets on win32), so we'd
>> still
>> have the "lose packets instead of blocking when falling behind".
>
> Right.
Please correct me if I am wrong, but using UDP logging on the same
computer is a red herring. Any non-blocking I/O would do, no? If the
buffer is full, then the non-blocking I/O send function will fail and
the message is skipped.
Has anyone observed UDP ever drop *written* packets on loopback?
Looking at the Darwin 8 sources, it appears that the loopback streams
all converge to the same stream code, which makes sense...
If a kernel is too busy to handle I/O, doesn't it have higher
priorities than switching to a user context?