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

[Eugene Sajine <euguess@gmail.com>]

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.
>
>