I'm confused. Piped logging did work just fine on Windows, unless something
has broken it.
The design goal was simply to support multiple processes some day. And the
code in question was proof-of-concept, that we could perform fd inheritance al
la *nix. But the cross process locking for appe
On Tue, Sep 23, 2014 at 4:01 PM, Eric Covener wrote:
>
> I was looking into an error where after a large # of rotatelogs
> processes are created, they start mysteriously exiting. I
>
For posterity, the initial problem is windows-only too, not just the
chance to save some piped loggers.
On Sep 23, 2014 4:01 PM, "Eric Covener" wrote:
>
>
> I was looking into an error where after a large # of rotatelogs
processes are created, they start mysteriously exiting. I
>
> I still don't know much about the problem, but it struck me that unlike
the error log, there doesn't seem to be a go
I was looking into an error where after a large # of rotatelogs processes
are created, they start mysteriously exiting. I
I still don't know much about the problem, but it struck me that unlike the
error log, there doesn't seem to be a good reason for the parent on Windows
to open (potentially
APR:
Considering that before we know it, http/2.0 will
be here, and ignoring httpd for the time being,
what features/additions do we see as being needed
to support http/2.0 from an APR library level? How do
we compare w/ libuv, for example? How "event-aware"
should APR be, ala libevent?
HTTPD:
Fro
