On Sun, Dec 07, 2008 at 07:22:32PM +0100, [EMAIL PROTECTED] wrote:
> > Nie jest i nie będzie -- zapomniałem wywalić. I nie rozumiem za bardzo
> > po co w ekg inny resolver niż fork(). Czyżby były używane wątki? :)
>
> Jeżeli libgadu jest skompilowane z wątkami to czemu nie? :) Zostawiłbyś
> w ekg
07.12.08 [EMAIL PROTECTED] napisał:
> > Dodaję do ekg zmienną resolver i oprócz gg_login_params chciałbym wywołać
> > po jej zmianie funkcję gg_global_set_resolver(), ale wygląda na to, że nie
> > jest nigdzie zdefiniowana:
>
> Nie jest i nie będzie -- zapomniałem wywalić. I nie rozumiem za bar
[EMAIL PROTECTED] pisze:
>> Zmiany commitnięte. Od tej pory domyślnie będą kompilowane oba
>> resolvery, domyślny będzie fork. Jeśli wybrano --with-pthread, domyślny
>> będzie pthread, a przy --without-pthread pthread w ogóle nie będzie
>> dostępny. Dzięki temu zachowanie biblioteki względem staryc
07.12.08 [EMAIL PROTECTED] napisał:
> Zmiany commitnięte. Od tej pory domyślnie będą kompilowane oba
> resolvery, domyślny będzie fork. Jeśli wybrano --with-pthread, domyślny
> będzie pthread, a przy --without-pthread pthread w ogóle nie będzie
> dostępny. Dzięki temu zachowanie biblioteki względe
07.12.08 [EMAIL PROTECTED] napisał:
> Zmiany commitnięte. Od tej pory domyślnie będą kompilowane oba
> resolvery, domyślny będzie fork. Jeśli wybrano --with-pthread, domyślny
> będzie pthread, a przy --without-pthread pthread w ogóle nie będzie
> dostępny. Dzięki temu zachowanie biblioteki względe
Wojtek Kaniewski pisze:
> (...)
Zmiany commitnięte. Od tej pory domyślnie będą kompilowane oba
resolvery, domyślny będzie fork. Jeśli wybrano --with-pthread, domyślny
będzie pthread, a przy --without-pthread pthread w ogóle nie będzie
dostępny. Dzięki temu zachowanie biblioteki względem starych we
Dnia 3-12-2008 o godz. 23:38 Wojtek Kaniewski napisał(a):
> [EMAIL PROTECTED] pisze:
> >> Można albo dodać zmienną globalną, która określi rodzaj resolvera
> >> (zwykle ustala się to raz na początku), albo dodać parametr do każdej
> >> funkcji, która rozpoczyna połączenie. Ani to, ani to nie jest i
[EMAIL PROTECTED] pisze:
>> Można albo dodać zmienną globalną, która określi rodzaj resolvera
>> (zwykle ustala się to raz na początku), albo dodać parametr do każdej
>> funkcji, która rozpoczyna połączenie. Ani to, ani to nie jest idealnym
>> rozwiązaniem, ale skłaniałbym się ku zmiennej globalnej
[EMAIL PROTECTED] pisze:
>> int (*resolver_start)(int *fd, void **priv_data, const char *hostname);
>> void (*resolver_cleanup)(void **priv_data, int force);
>
> W kwestii estetyki - jak start to bardziej pasuje end, a jak cleanup to
> init :)
start startuje, ale resolvowanie kończy się samo. cl
02.12.08 [EMAIL PROTECTED] napisał:
> int (*resolver_start)(int *fd, void **priv_data, const char *hostname);
> void (*resolver_cleanup)(void **priv_data, int force);
W kwestii estetyki - jak start to bardziej pasuje end, a jak cleanup to
init :)
Jak dla mnie jest ok.
> wystarczy? Dla fork() i
Jakub Zawadzki pisze:
> A mozna poprosic aby mozna bylo ustawic wlasna funkcje?
> W sumie nie wiem po co - ale moze komus sie przyda :)
Też o tym myślałem, co prawda uznałem to za zbytnią ekstrawagancję, ale
widzę, że do tego wrócę. Czy takie API...
int (*resolver_start)(int *fd, void **priv_data
02.12.08 [EMAIL PROTECTED] napisał:
> > Myślę że zmienna globalna i funkcja typu gg_set_resolver(), przyjmująca
> > enumem trzy wartości - default, fork, pthread.
>
> A mozna poprosic aby mozna bylo ustawic wlasna funkcje?
> W sumie nie wiem po co - ale moze komus sie przyda :)
O właśnie, albo
On Mon, Dec 01, 2008 at 11:32:24PM +0100, [EMAIL PROTECTED] wrote:
> 01.12.08 [EMAIL PROTECTED] napisał:
>
> > Można albo dodać zmienną globalną, która określi rodzaj resolvera
> > (zwykle ustala się to raz na początku), albo dodać parametr do każdej
> > funkcji, która rozpoczyna połączenie. Ani t
On poniedziałek 01 grudnia 2008 23:26:58 Wojtek Kaniewski wrote:
> Hej,
>
> Korzystając z wolnej chwili chcę naprawić mało sensowny sposób
> wybierania resolvera na etapie kompilacji. Nic nie stoi na przeszkodzie,
> żeby móc wybierać między fork() a pthread w czasie pracy. O ile przy
> połączeniu z
01.12.08 [EMAIL PROTECTED] napisał:
> Można albo dodać zmienną globalną, która określi rodzaj resolvera
> (zwykle ustala się to raz na początku), albo dodać parametr do każdej
> funkcji, która rozpoczyna połączenie. Ani to, ani to nie jest idealnym
> rozwiązaniem, ale skłaniałbym się ku zmiennej g
Hej,
Korzystając z wolnej chwili chcę naprawić mało sensowny sposób
wybierania resolvera na etapie kompilacji. Nic nie stoi na przeszkodzie,
żeby móc wybierać między fork() a pthread w czasie pracy. O ile przy
połączeniu z serwerem nie ma problemu, bo wystarczy dodać kolejne pole
do gg_login_param
16 matches
Mail list logo
