On Thu, Sep 12, 2013 at 5:16 PM, Eugene Sajine <euguess@xxxxxxxxx> wrote: > 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@xxxxxxxxx> wrote: >> Eugene Sajine <euguess@xxxxxxxxx> 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. >> >> For now I'm trying to do the following: access-hook.bash has: delayed-notify.bash $@ & delayed-notify.bash has: sleep 10 ... curl ... I'm expecting access-hook to spawn new process and return without waiting for it to finish to let the service to do its job. But when i do push - it sleeps for 10 seconds anyway. Am i missing something obvious here? Any help is much appreciated! Thanks, Eugene -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html