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!


On Thu, Sep 12, 2013 at 5:08 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Eugene Sajine <eugu...@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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to