Re: Fwd: Fwd: git-daemon access-hook race condition

> Junio,
>
> Thanks for the clarification! Your solution does look better.
>
> For now though i think i will have to delay the notification somehow
> and let the service finish first then notify the server.
>
> Thanks again!
>
> Eugene
>
>
> On Thu, Sep 12, 2013 at 5:08 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Eugene Sajine <euguess@gmail.com> writes:
>>
>>> So are you really sure that it is a non-starter to have
>>> --before-service/--after-service options for access-hook?
>>
>> Given the definition of "--access-hook" in "git help daemon":
>>
>>     --access-hook=<path>::
>>             Every time a client connects, first run an external command
>>             specified by the <path> ... The external command can decide
>>             to decline the service by exiting with a non-zero status (or
>>             to allow it by exiting with a zero status)....
>>
>> There is *NO* way in anywhere --after-service makes any sense (and
>> by definition --before-service is redundant).
>>
>> What you _could_ propose is to define a *new* hook that is run when
>> the spawned service has returned, with the same information that is
>> fed to the access hook (possibly with its exit status).
>>
>> I do not offhand know if we retain the original service information
>> that long after the main daemon process has spawned the service
>> process, though.  With the current system, the only thing it needs
>> to know is the PID of the service processes that are to be culled by
>> calls to waitpid().  So you may have to extend existing bookkeeping
>> data structures a bit to keep those pieces of information around if
>> you wanted to add such a new hook.
>>
>>