Mladen Turk wrote: > Hi, > > Currently rotatelogs (at least on windows) holds the initial > log file by parent process (well it tries to rotate if something > is written from parent which is impossible for access logs). > > I plan to use the apr_wait_for_io_or_timeout before calling > the apr_file_read(f_stdin, ...). This would give a chance > to parent to rotate his log as well and release the initial > log file descriptor. > > Would that make any problems if executed in the parent? > Since apr_wait_for_io_or_timeout is posix only API, some > #ifdef _WIN32 would be required in rotatelogs
Wouldn't it be better if we simply implement the mechanism to share the same handle between the parent and child? And reimplement the locking for append I deployed in apr, which was removed some time back? Just as we do with listeners? It seems long past time to define the API contract to accomplish this, and there are sufficient eyeballs to do it, finally. I'd leave rotatelogs alone, please. Its design is not flawed. But I think Jim was working on something which would release the file just as soon as its time is up, and that is useful across all of the architectures, not windows specific.
