Re: progress to serveez-0.2
Julian Graham <[email protected]> Tue, 13 Nov 2012 00:07:04 -0500
| Newsgroups | gmane.network.serveez.devel |
|---|---|
| Message-ID | <CANdC_RBz-G9VHxbO885TXxe94VO3RXMTPGNZMnM0FEr=mt0hnQ@mail.gmail.com> |
Hey ttn, Thanks for looking into this. On Sun, Nov 11, 2012 at 4:11 PM, Thien-Thi Nguyen <[email protected]> wrote: > Does your code call =91svz_updn_all_coservers=92? If so, you can try > omitting all calls (both the up and the down) and see how that flies. > (Ignorance is bliss.) If there are still problems, try this patch (to > src/libserveez/coserver/coserver.c): It was not calling `svz_updn_all_coservers'. > and on the initial (up) call, specify DIRECTION as -1. Ideally the > patch would not be necessary (because then i need to also add support > for serveez (the program) to take some kind of config (command-line?, > file-based?) specifying "no coserver instances" and propagate that down > to =91guile_entry=92 -- IOW, a bit messy). Unfortunately, your patch works like a charm. :) (Other than a small typo in that `for' loop.) Can you please include it in the release? > Looks reasonable to me. I see you don't call =91svz_updn_all_coservers= =92 > in this fragment -- are coservers still starting anyway? (That would be > weird and unexpected and likely-to-segfault, i think.) Yes, coservers were starting anyway. I've never interacted with (or wanted) coservers; they just seem to happen. :) My understanding of coserver behavior (from skimming the code) is that unless you do something magical to the coserver configurations, they get started on the first "tick" of the Serveez core code and any that exit get restarted on every subsequent tick. (See `svz_coserver_check' in coserver.c.)