From clayne at anodized.com Fri Jun 1 03:46:19 2007 From: clayne at anodized.com (Christopher Layne) Date: Fri Jun 1 03:46:23 2007 Subject: [Libevent-users] event.c:673 failed assertion Message-ID: <20070601074619.GA7197@ns1.anodized.com> recv timeout, event == 1, 3, 0 ^ From my own code, just debugging data, but pertinent in that it was just a timeout event which was received. Since it seems one cannot have a persistent time out event with a relative timeout (mentioned previously) - I always delete and re-add the specific receive event following a timeout. Right after... assertion "!(ev->ev_flags & ~EVLIST_ALL)" failed: file "event.c", line 673 My stack trace reveals these lines causing the issue: static int yc_recv_set(yc *y, int tout) { struct timeval tv; tv.tv_sec = tout; tv.tv_usec = 0; --> event_del(y->ev_r); event_add(y->ev_r, &tv); return 0; } No threading, no funky stuff, just a simple bounce function that I call within the receive handler. Any good places to start looking? It looks as though this assertion is to double-check that no "private" flags have been set. 1.3b on Cygwin, POSIX layer. For now I'll just hack the assertion to be a conditional which prints the suspect flags... -cl From bretthoerner at bretthoerner.com Fri Jun 1 11:16:13 2007 From: bretthoerner at bretthoerner.com (Brett Hoerner) Date: Fri Jun 1 11:16:21 2007 Subject: [Libevent-users] libevent on OpenSolaris with GCC --- port_dissociate: No such file or directory Message-ID: I'm having a tough time compiling libevent-1.3b on OpenSolaris. I followed a bunch of clues from this list and others including: Replace all usages of 'u_int*_t' with 'uint*_t'. Replace '__inline' with 'inline' Run configure with LDFLAGS="-lnsl -lresolv" I also used someones' Solaris patch that added some includes in desperation (all in my diff). I'm able to compile it now, but when I run the tests or when I compile memcached against it and make use of memcached, I get the following error on each event (I guess): port_dissociate: No such file or directory Google tells me nothing. :( This is the output of my the libevent test.sh: ----- Running tests: KQUEUE test-eof: port_dissociate: No such file or directory port_dissociate: No such file or directory OKAY test-weof: port_dissociate: No such file or directory port_dissociate: No such file or directory OKAY test-time: OKAY regress: port_dissociate: No such file or directory port_dissociate: No such file or directory [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on request 806c0c0 from 127.0.0.1 port_dissociate: No such file or directory port_dissociate: No such file or directory port_dissociate: No such file or directory FAILED DEVPOLL test-eof: port_dissociate: No such file or directory port_dissociate: No such file or directory OKAY test-weof: port_dissociate: No such file or directory port_dissociate: No such file or directory OKAY test-time: OKAY regress: port_dissociate: No such file or directory port_dissociate: No such file or directory [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on request 806c0c0 from 127.0.0.1 port_dissociate: No such file or directory port_dissociate: No such file or directory port_dissociate: No such file or directory FAILED POLL test-eof: port_dissociate: No such file or directory port_dissociate: No such file or directory OKAY test-weof: port_dissociate: No such file or directory port_dissociate: No such file or directory OKAY test-time: OKAY regress: port_dissociate: No such file or directory port_dissociate: No such file or directory [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on request 806c0c0 from 127.0.0.1 port_dissociate: No such file or directory port_dissociate: No such file or directory port_dissociate: No such file or directory FAILED SELECT test-eof: port_dissociate: No such file or directory port_dissociate: No such file or directory OKAY test-weof: port_dissociate: No such file or directory port_dissociate: No such file or directory OKAY test-time: OKAY regress: port_dissociate: No such file or directory port_dissociate: No such file or directory [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on request 806c0c0 from 127.0.0.1 port_dissociate: No such file or directory port_dissociate: No such file or directory port_dissociate: No such file or directory FAILED RTSIG test-eof: port_dissociate: No such file or directory port_dissociate: No such file or directory OKAY test-weof: port_dissociate: No such file or directory port_dissociate: No such file or directory OKAY test-time: OKAY regress: port_dissociate: No such file or directory port_dissociate: No such file or directory [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on request 806c0c0 from 127.0.0.1 port_dissociate: No such file or directory port_dissociate: No such file or directory port_dissociate: No such file or directory FAILED EPOLL test-eof: port_dissociate: No such file or directory port_dissociate: No such file or directory OKAY test-weof: port_dissociate: No such file or directory port_dissociate: No such file or directory OKAY test-time: OKAY regress: port_dissociate: No such file or directory port_dissociate: No such file or directory [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on request 806c0c0 from 127.0.0.1 port_dissociate: No such file or directory port_dissociate: No such file or directory port_dissociate: No such file or directory FAILED ----- I have no idea if they should all be passing, or if failing is a nice way of saying "this method isn't supported on OpenSolaris". For the record, using memcached does work, I can set and fetch objects... but I'm concerned about the complaints of port_dissociate. Assuming attachments work, I've attached what I've changed against default 1.3b to get this to compile as it is now... if it helps. Thanks in advance for any wisdom, Brett -------------- next part -------------- A non-text attachment was scrubbed... Name: libevent.diff Type: application/octet-stream Size: 8473 bytes Desc: not available Url : http://monkeymail.org/archives/libevent-users/attachments/20070601/d0e789a4/libevent-0001.obj From bretthoerner at bretthoerner.com Fri Jun 1 14:41:29 2007 From: bretthoerner at bretthoerner.com (Brett Hoerner) Date: Fri Jun 1 14:41:34 2007 Subject: [Libevent-users] libevent on OpenSolaris with GCC --- port_dissociate: No such file or directory In-Reply-To: References: Message-ID: Thanks, that killed the specific complaint/error, but do I want to disable event ports? Isn't that Solaris' most fancy event system? And should I worry about the evhttp_parse_request_line lines? Sorry for being useless here. :( --- Running tests: KQUEUE Skipping test DEVPOLL test-eof: OKAY test-weof: OKAY test-time: OKAY regress: [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on request 8072028 from 127.0.0.1 FAILED POLL test-eof: OKAY test-weof: OKAY test-time: OKAY regress: [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on request 806b218 from 127.0.0.1 FAILED SELECT test-eof: OKAY test-weof: OKAY test-time: OKAY regress: [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on request 806c220 from 127.0.0.1 FAILED RTSIG Skipping test EPOLL Skipping test --- Thanks, Brett On 6/1/07, Andrew Danforth wrote: > Try setting EVENT_NOEVPORT to 1 in your environment (export > EVENT_NOEVPORT=1). That will disable the Solaris event ports code which is > probably what is causing your port_disassociate errors. Can't say whether > or not it will uncover other problems, though. > > A > > On 6/1/07, Brett Hoerner wrote: > > > > I'm having a tough time compiling libevent-1.3b on OpenSolaris. I > > followed a bunch of clues from this list and others including: > > > > Replace all usages of 'u_int*_t' with 'uint*_t'. > > Replace '__inline' with 'inline' > > Run configure with LDFLAGS="-lnsl -lresolv" > > > > I also used someones' Solaris patch that added some includes in > > desperation (all in my diff). > > > > I'm able to compile it now, but when I run the tests or when I compile > > memcached against it and make use of memcached, I get the following > > error on each event (I guess): > > > > port_dissociate: No such file or directory > > > > Google tells me nothing. :( > > > > This is the output of my the libevent test.sh: > > > > ----- > > > > Running tests: > > KQUEUE > > test-eof: port_dissociate: No such file or directory > > port_dissociate: No such file or directory > > OKAY > > test-weof: port_dissociate: No such file or directory > > port_dissociate: No such file or directory > > OKAY > > test-time: OKAY > > regress: port_dissociate: No such file or directory > > port_dissociate: No such file or directory > > [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on > > request 806c0c0 from 127.0.0.1 > > port_dissociate: No such file or directory > > port_dissociate: No such file or directory > > port_dissociate: No such file or directory > > FAILED > > DEVPOLL > > test-eof: port_dissociate: No such file or directory > > port_dissociate: No such file or directory > > OKAY > > test-weof: port_dissociate: No such file or directory > > port_dissociate: No such file or directory > > OKAY > > test-time: OKAY > > regress: port_dissociate: No such file or directory > > port_dissociate: No such file or directory > > [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on > > request 806c0c0 from 127.0.0.1 > > port_dissociate: No such file or directory > > port_dissociate: No such file or directory > > port_dissociate: No such file or directory > > FAILED > > POLL > > test-eof: port_dissociate: No such file or directory > > port_dissociate: No such file or directory > > OKAY > > test-weof: port_dissociate: No such file or directory > > port_dissociate: No such file or directory > > OKAY > > test-time: OKAY > > regress: port_dissociate: No such file or directory > > port_dissociate: No such file or directory > > [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on > > request 806c0c0 from 127.0.0.1 > > port_dissociate: No such file or directory > > port_dissociate: No such file or directory > > port_dissociate: No such file or directory > > FAILED > > SELECT > > test-eof: port_dissociate: No such file or directory > > port_dissociate: No such file or directory > > OKAY > > test-weof: port_dissociate: No such file or directory > > port_dissociate: No such file or directory > > OKAY > > test-time: OKAY > > regress: port_dissociate: No such file or directory > > port_dissociate: No such file or directory > > [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on > > request 806c0c0 from 127.0.0.1 > > port_dissociate: No such file or directory > > port_dissociate: No such file or directory > > port_dissociate: No such file or directory > > FAILED > > RTSIG > > test-eof: port_dissociate: No such file or directory > > port_dissociate: No such file or directory > > OKAY > > test-weof: port_dissociate: No such file or directory > > port_dissociate: No such file or directory > > OKAY > > test-time: OKAY > > regress: port_dissociate: No such file or directory > > port_dissociate: No such file or directory > > [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on > > request 806c0c0 from 127.0.0.1 > > port_dissociate: No such file or directory > > port_dissociate: No such file or directory > > port_dissociate: No such file or directory > > FAILED > > EPOLL > > test-eof: port_dissociate: No such file or directory > > port_dissociate: No such file or directory > > OKAY > > test-weof: port_dissociate: No such file or directory > > port_dissociate: No such file or directory > > OKAY > > test-time: OKAY > > regress: port_dissociate: No such file or directory > > port_dissociate: No such file or directory > > [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on > > request 806c0c0 from 127.0.0.1 > > port_dissociate: No such file or directory > > port_dissociate: No such file or directory > > port_dissociate: No such file or directory > > FAILED > > > > ----- > > > > I have no idea if they should all be passing, or if failing is a nice > > way of saying "this method isn't supported on OpenSolaris". For the > > record, using memcached does work, I can set and fetch objects... but > > I'm concerned about the complaints of port_dissociate. > > > > Assuming attachments work, I've attached what I've changed against > > default 1.3b to get this to compile as it is now... if it helps. > > > > Thanks in advance for any wisdom, > > Brett > > > > _______________________________________________ > > Libevent-users mailing list > > Libevent-users@monkey.org > > http://monkey.org/mailman/listinfo/libevent-users > > > > > > > > From acd at weirdness.net Fri Jun 1 14:37:04 2007 From: acd at weirdness.net (Andrew Danforth) Date: Fri Jun 1 14:47:08 2007 Subject: [Libevent-users] libevent on OpenSolaris with GCC --- port_dissociate: No such file or directory In-Reply-To: References: Message-ID: Try setting EVENT_NOEVPORT to 1 in your environment (export EVENT_NOEVPORT=1). That will disable the Solaris event ports code which is probably what is causing your port_disassociate errors. Can't say whether or not it will uncover other problems, though. A On 6/1/07, Brett Hoerner wrote: > > I'm having a tough time compiling libevent-1.3b on OpenSolaris. I > followed a bunch of clues from this list and others including: > > Replace all usages of 'u_int*_t' with 'uint*_t'. > Replace '__inline' with 'inline' > Run configure with LDFLAGS="-lnsl -lresolv" > > I also used someones' Solaris patch that added some includes in > desperation (all in my diff). > > I'm able to compile it now, but when I run the tests or when I compile > memcached against it and make use of memcached, I get the following > error on each event (I guess): > > port_dissociate: No such file or directory > > Google tells me nothing. :( > > This is the output of my the libevent test.sh: > > ----- > > Running tests: > KQUEUE > test-eof: port_dissociate: No such file or directory > port_dissociate: No such file or directory > OKAY > test-weof: port_dissociate: No such file or directory > port_dissociate: No such file or directory > OKAY > test-time: OKAY > regress: port_dissociate: No such file or directory > port_dissociate: No such file or directory > [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on > request 806c0c0 from 127.0.0.1 > port_dissociate: No such file or directory > port_dissociate: No such file or directory > port_dissociate: No such file or directory > FAILED > DEVPOLL > test-eof: port_dissociate: No such file or directory > port_dissociate: No such file or directory > OKAY > test-weof: port_dissociate: No such file or directory > port_dissociate: No such file or directory > OKAY > test-time: OKAY > regress: port_dissociate: No such file or directory > port_dissociate: No such file or directory > [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on > request 806c0c0 from 127.0.0.1 > port_dissociate: No such file or directory > port_dissociate: No such file or directory > port_dissociate: No such file or directory > FAILED > POLL > test-eof: port_dissociate: No such file or directory > port_dissociate: No such file or directory > OKAY > test-weof: port_dissociate: No such file or directory > port_dissociate: No such file or directory > OKAY > test-time: OKAY > regress: port_dissociate: No such file or directory > port_dissociate: No such file or directory > [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on > request 806c0c0 from 127.0.0.1 > port_dissociate: No such file or directory > port_dissociate: No such file or directory > port_dissociate: No such file or directory > FAILED > SELECT > test-eof: port_dissociate: No such file or directory > port_dissociate: No such file or directory > OKAY > test-weof: port_dissociate: No such file or directory > port_dissociate: No such file or directory > OKAY > test-time: OKAY > regress: port_dissociate: No such file or directory > port_dissociate: No such file or directory > [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on > request 806c0c0 from 127.0.0.1 > port_dissociate: No such file or directory > port_dissociate: No such file or directory > port_dissociate: No such file or directory > FAILED > RTSIG > test-eof: port_dissociate: No such file or directory > port_dissociate: No such file or directory > OKAY > test-weof: port_dissociate: No such file or directory > port_dissociate: No such file or directory > OKAY > test-time: OKAY > regress: port_dissociate: No such file or directory > port_dissociate: No such file or directory > [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on > request 806c0c0 from 127.0.0.1 > port_dissociate: No such file or directory > port_dissociate: No such file or directory > port_dissociate: No such file or directory > FAILED > EPOLL > test-eof: port_dissociate: No such file or directory > port_dissociate: No such file or directory > OKAY > test-weof: port_dissociate: No such file or directory > port_dissociate: No such file or directory > OKAY > test-time: OKAY > regress: port_dissociate: No such file or directory > port_dissociate: No such file or directory > [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on > request 806c0c0 from 127.0.0.1 > port_dissociate: No such file or directory > port_dissociate: No such file or directory > port_dissociate: No such file or directory > FAILED > > ----- > > I have no idea if they should all be passing, or if failing is a nice > way of saying "this method isn't supported on OpenSolaris". For the > record, using memcached does work, I can set and fetch objects... but > I'm concerned about the complaints of port_dissociate. > > Assuming attachments work, I've attached what I've changed against > default 1.3b to get this to compile as it is now... if it helps. > > Thanks in advance for any wisdom, > Brett > > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20070601/dced42ad/attachment.htm From provos at citi.umich.edu Fri Jun 1 17:43:26 2007 From: provos at citi.umich.edu (Niels Provos) Date: Fri Jun 1 17:43:30 2007 Subject: [Libevent-users] libevent on OpenSolaris with GCC --- port_dissociate: No such file or directory In-Reply-To: References: Message-ID: <850f7cbe0706011443h5d48aca2m33d310c8eaad7f93@mail.gmail.com> I don't have access to Solaris. The only way this can be fixed is by people running Solaris to send patches. Niels. On 6/1/07, Brett Hoerner wrote: > Thanks, that killed the specific complaint/error, but do I want to > disable event ports? Isn't that Solaris' most fancy event system? > And should I worry about the evhttp_parse_request_line lines? > > Sorry for being useless here. :( > > --- > > Running tests: > KQUEUE > Skipping test > DEVPOLL > test-eof: OKAY > test-weof: OKAY > test-time: OKAY > regress: [warn] evhttp_parse_request_line: bad method GET /test > HTTP/1.1 on request 8072028 from 127.0.0.1 > FAILED > POLL > test-eof: OKAY > test-weof: OKAY > test-time: OKAY > regress: [warn] evhttp_parse_request_line: bad method GET /test > HTTP/1.1 on request 806b218 from 127.0.0.1 > FAILED > SELECT > test-eof: OKAY > test-weof: OKAY > test-time: OKAY > regress: [warn] evhttp_parse_request_line: bad method GET /test > HTTP/1.1 on request 806c220 from 127.0.0.1 > FAILED > RTSIG > Skipping test > EPOLL > Skipping test > > --- > > Thanks, > Brett > > > > On 6/1/07, Andrew Danforth wrote: > > Try setting EVENT_NOEVPORT to 1 in your environment (export > > EVENT_NOEVPORT=1). That will disable the Solaris event ports code which is > > probably what is causing your port_disassociate errors. Can't say whether > > or not it will uncover other problems, though. > > > > A > > > > On 6/1/07, Brett Hoerner wrote: > > > > > > I'm having a tough time compiling libevent-1.3b on OpenSolaris. I > > > followed a bunch of clues from this list and others including: > > > > > > Replace all usages of 'u_int*_t' with 'uint*_t'. > > > Replace '__inline' with 'inline' > > > Run configure with LDFLAGS="-lnsl -lresolv" > > > > > > I also used someones' Solaris patch that added some includes in > > > desperation (all in my diff). > > > > > > I'm able to compile it now, but when I run the tests or when I compile > > > memcached against it and make use of memcached, I get the following > > > error on each event (I guess): > > > > > > port_dissociate: No such file or directory > > > > > > Google tells me nothing. :( > > > > > > This is the output of my the libevent test.sh: > > > > > > ----- > > > > > > Running tests: > > > KQUEUE > > > test-eof: port_dissociate: No such file or directory > > > port_dissociate: No such file or directory > > > OKAY > > > test-weof: port_dissociate: No such file or directory > > > port_dissociate: No such file or directory > > > OKAY > > > test-time: OKAY > > > regress: port_dissociate: No such file or directory > > > port_dissociate: No such file or directory > > > [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on > > > request 806c0c0 from 127.0.0.1 > > > port_dissociate: No such file or directory > > > port_dissociate: No such file or directory > > > port_dissociate: No such file or directory > > > FAILED > > > DEVPOLL > > > test-eof: port_dissociate: No such file or directory > > > port_dissociate: No such file or directory > > > OKAY > > > test-weof: port_dissociate: No such file or directory > > > port_dissociate: No such file or directory > > > OKAY > > > test-time: OKAY > > > regress: port_dissociate: No such file or directory > > > port_dissociate: No such file or directory > > > [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on > > > request 806c0c0 from 127.0.0.1 > > > port_dissociate: No such file or directory > > > port_dissociate: No such file or directory > > > port_dissociate: No such file or directory > > > FAILED > > > POLL > > > test-eof: port_dissociate: No such file or directory > > > port_dissociate: No such file or directory > > > OKAY > > > test-weof: port_dissociate: No such file or directory > > > port_dissociate: No such file or directory > > > OKAY > > > test-time: OKAY > > > regress: port_dissociate: No such file or directory > > > port_dissociate: No such file or directory > > > [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on > > > request 806c0c0 from 127.0.0.1 > > > port_dissociate: No such file or directory > > > port_dissociate: No such file or directory > > > port_dissociate: No such file or directory > > > FAILED > > > SELECT > > > test-eof: port_dissociate: No such file or directory > > > port_dissociate: No such file or directory > > > OKAY > > > test-weof: port_dissociate: No such file or directory > > > port_dissociate: No such file or directory > > > OKAY > > > test-time: OKAY > > > regress: port_dissociate: No such file or directory > > > port_dissociate: No such file or directory > > > [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on > > > request 806c0c0 from 127.0.0.1 > > > port_dissociate: No such file or directory > > > port_dissociate: No such file or directory > > > port_dissociate: No such file or directory > > > FAILED > > > RTSIG > > > test-eof: port_dissociate: No such file or directory > > > port_dissociate: No such file or directory > > > OKAY > > > test-weof: port_dissociate: No such file or directory > > > port_dissociate: No such file or directory > > > OKAY > > > test-time: OKAY > > > regress: port_dissociate: No such file or directory > > > port_dissociate: No such file or directory > > > [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on > > > request 806c0c0 from 127.0.0.1 > > > port_dissociate: No such file or directory > > > port_dissociate: No such file or directory > > > port_dissociate: No such file or directory > > > FAILED > > > EPOLL > > > test-eof: port_dissociate: No such file or directory > > > port_dissociate: No such file or directory > > > OKAY > > > test-weof: port_dissociate: No such file or directory > > > port_dissociate: No such file or directory > > > OKAY > > > test-time: OKAY > > > regress: port_dissociate: No such file or directory > > > port_dissociate: No such file or directory > > > [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on > > > request 806c0c0 from 127.0.0.1 > > > port_dissociate: No such file or directory > > > port_dissociate: No such file or directory > > > port_dissociate: No such file or directory > > > FAILED > > > > > > ----- > > > > > > I have no idea if they should all be passing, or if failing is a nice > > > way of saying "this method isn't supported on OpenSolaris". For the > > > record, using memcached does work, I can set and fetch objects... but > > > I'm concerned about the complaints of port_dissociate. > > > > > > Assuming attachments work, I've attached what I've changed against > > > default 1.3b to get this to compile as it is now... if it helps. > > > > > > Thanks in advance for any wisdom, > > > Brett > > > > > > _______________________________________________ > > > Libevent-users mailing list > > > Libevent-users@monkey.org > > > http://monkey.org/mailman/listinfo/libevent-users > > > > > > > > > > > > > > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users > > From provos at citi.umich.edu Sat Jun 2 19:22:08 2007 From: provos at citi.umich.edu (Niels Provos) Date: Sat Jun 2 19:22:17 2007 Subject: [Libevent-users] event.c:673 failed assertion In-Reply-To: <20070601074619.GA7197@ns1.anodized.com> References: <20070601074619.GA7197@ns1.anodized.com> Message-ID: <850f7cbe0706021622o7f68b1f0yc6979bf61e864f7f@mail.gmail.com> Without seeing your full code, it's hard to see what the problem might be. In most cases, where these kind of asserts fail, it's due to memory corruption. An early free of the data structure could be one possible cause. Niels. On 6/1/07, Christopher Layne wrote: > recv timeout, event == 1, 3, 0 > ^ From my own code, just debugging data, but pertinent in that it was just a timeout > event which was received. Since it seems one cannot have a persistent time out event > with a relative timeout (mentioned previously) - I always delete and re-add the specific > receive event following a timeout. Right after... > > assertion "!(ev->ev_flags & ~EVLIST_ALL)" failed: file "event.c", line 673 > > > My stack trace reveals these lines causing the issue: > > static int yc_recv_set(yc *y, int tout) > { > struct timeval tv; > > tv.tv_sec = tout; > tv.tv_usec = 0; > > --> event_del(y->ev_r); > event_add(y->ev_r, &tv); > > return 0; > } > > No threading, no funky stuff, just a simple bounce function that I call within > the receive handler. Any good places to start looking? It looks as though this assertion > is to double-check that no "private" flags have been set. 1.3b on Cygwin, POSIX layer. > For now I'll just hack the assertion to be a conditional which prints the suspect flags... > > -cl > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users > > From pcloches at gmail.com Wed Jun 6 14:24:56 2007 From: pcloches at gmail.com (Patrick Clochesy) Date: Wed Jun 6 14:25:00 2007 Subject: [Libevent-users] Threading support question Message-ID: <34394a3a0706061124r29c9ab5cu171e0bc575f26f6f@mail.gmail.com> Here's a quick synopsis for those who don't want to read the whole explanation :) Is it possible to create events in threads that will fire in the main thread if the access to event_set is mutually exclusive? Longer explanation: After I already implemented a multithreaded server based on libevent, I saw Steven's message about the threading support. I basically have one thread which does all the I/O, two other types of threads. The first handles all the accepts and sends a welcome message to each new thread (using libevent if the call to write() doesn't write all the bytes). The second is actually a group of threads which are in charge of authenticating. I had planned on all the threads being able to be able to create new write events using libevent, since the accept()ing threads need to send the protocol "welcome" and also create a read event for when data arrives, and the authentication threads need to send back to the client whether they authenticated or not. However, before having seen this I implemented it, and the event_set in the accept() thread is creating an event that is fired in the main threads event_dispatch(). So, is it okay to continue on this path if I assure the access of the libevent objects are mutually exclusive? Thanks, -Patrick From Shanti.Subramanyam at Sun.COM Wed Jun 6 14:51:09 2007 From: Shanti.Subramanyam at Sun.COM (Shanti Subramanyam - PAE) Date: Wed Jun 6 14:51:30 2007 Subject: [Libevent-users] libevent on OpenSolaris with GCC --- port_dissociate: No such file or directory In-Reply-To: References: Message-ID: <4667021D.9010600@Sun.COM> You do want to use event ports on Solaris and it works fine. Please go to http://cooltools.sunsource.net/coolstack and download the CSKmemcached package. This is a binary distribution and will work on opensolaris. Alternatively, if you are really particular on building libevent/memcached yourself, you can get it from the svn repository of the opensolaris web stack project (http://opensolaris.org/os/project/webstack). The directories include all the fixes and a build script for a clean build on Solaris. Note that if you want to use the latest memcached source, please do read the README/make scripts in the sources I pointed to above and port them over. Shanti Brett Hoerner wrote: > Thanks, that killed the specific complaint/error, but do I want to > disable event ports? Isn't that Solaris' most fancy event system? > And should I worry about the evhttp_parse_request_line lines? > > Sorry for being useless here. :( > > --- > > Running tests: > KQUEUE > Skipping test > DEVPOLL > test-eof: OKAY > test-weof: OKAY > test-time: OKAY > regress: [warn] evhttp_parse_request_line: bad method GET /test > HTTP/1.1 on request 8072028 from 127.0.0.1 > FAILED > POLL > test-eof: OKAY > test-weof: OKAY > test-time: OKAY > regress: [warn] evhttp_parse_request_line: bad method GET /test > HTTP/1.1 on request 806b218 from 127.0.0.1 > FAILED > SELECT > test-eof: OKAY > test-weof: OKAY > test-time: OKAY > regress: [warn] evhttp_parse_request_line: bad method GET /test > HTTP/1.1 on request 806c220 from 127.0.0.1 > FAILED > RTSIG > Skipping test > EPOLL > Skipping test > > --- > > Thanks, > Brett > > > > On 6/1/07, Andrew Danforth wrote: >> Try setting EVENT_NOEVPORT to 1 in your environment (export >> EVENT_NOEVPORT=1). That will disable the Solaris event ports code >> which is >> probably what is causing your port_disassociate errors. Can't say >> whether >> or not it will uncover other problems, though. >> >> A >> >> On 6/1/07, Brett Hoerner wrote: >> > >> > I'm having a tough time compiling libevent-1.3b on OpenSolaris. I >> > followed a bunch of clues from this list and others including: >> > >> > Replace all usages of 'u_int*_t' with 'uint*_t'. >> > Replace '__inline' with 'inline' >> > Run configure with LDFLAGS="-lnsl -lresolv" >> > >> > I also used someones' Solaris patch that added some includes in >> > desperation (all in my diff). >> > >> > I'm able to compile it now, but when I run the tests or when I compile >> > memcached against it and make use of memcached, I get the following >> > error on each event (I guess): >> > >> > port_dissociate: No such file or directory >> > >> > Google tells me nothing. :( >> > >> > This is the output of my the libevent test.sh: >> > >> > ----- >> > >> > Running tests: >> > KQUEUE >> > test-eof: port_dissociate: No such file or directory >> > port_dissociate: No such file or directory >> > OKAY >> > test-weof: port_dissociate: No such file or directory >> > port_dissociate: No such file or directory >> > OKAY >> > test-time: OKAY >> > regress: port_dissociate: No such file or directory >> > port_dissociate: No such file or directory >> > [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on >> > request 806c0c0 from 127.0.0.1 >> > port_dissociate: No such file or directory >> > port_dissociate: No such file or directory >> > port_dissociate: No such file or directory >> > FAILED >> > DEVPOLL >> > test-eof: port_dissociate: No such file or directory >> > port_dissociate: No such file or directory >> > OKAY >> > test-weof: port_dissociate: No such file or directory >> > port_dissociate: No such file or directory >> > OKAY >> > test-time: OKAY >> > regress: port_dissociate: No such file or directory >> > port_dissociate: No such file or directory >> > [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on >> > request 806c0c0 from 127.0.0.1 >> > port_dissociate: No such file or directory >> > port_dissociate: No such file or directory >> > port_dissociate: No such file or directory >> > FAILED >> > POLL >> > test-eof: port_dissociate: No such file or directory >> > port_dissociate: No such file or directory >> > OKAY >> > test-weof: port_dissociate: No such file or directory >> > port_dissociate: No such file or directory >> > OKAY >> > test-time: OKAY >> > regress: port_dissociate: No such file or directory >> > port_dissociate: No such file or directory >> > [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on >> > request 806c0c0 from 127.0.0.1 >> > port_dissociate: No such file or directory >> > port_dissociate: No such file or directory >> > port_dissociate: No such file or directory >> > FAILED >> > SELECT >> > test-eof: port_dissociate: No such file or directory >> > port_dissociate: No such file or directory >> > OKAY >> > test-weof: port_dissociate: No such file or directory >> > port_dissociate: No such file or directory >> > OKAY >> > test-time: OKAY >> > regress: port_dissociate: No such file or directory >> > port_dissociate: No such file or directory >> > [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on >> > request 806c0c0 from 127.0.0.1 >> > port_dissociate: No such file or directory >> > port_dissociate: No such file or directory >> > port_dissociate: No such file or directory >> > FAILED >> > RTSIG >> > test-eof: port_dissociate: No such file or directory >> > port_dissociate: No such file or directory >> > OKAY >> > test-weof: port_dissociate: No such file or directory >> > port_dissociate: No such file or directory >> > OKAY >> > test-time: OKAY >> > regress: port_dissociate: No such file or directory >> > port_dissociate: No such file or directory >> > [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on >> > request 806c0c0 from 127.0.0.1 >> > port_dissociate: No such file or directory >> > port_dissociate: No such file or directory >> > port_dissociate: No such file or directory >> > FAILED >> > EPOLL >> > test-eof: port_dissociate: No such file or directory >> > port_dissociate: No such file or directory >> > OKAY >> > test-weof: port_dissociate: No such file or directory >> > port_dissociate: No such file or directory >> > OKAY >> > test-time: OKAY >> > regress: port_dissociate: No such file or directory >> > port_dissociate: No such file or directory >> > [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on >> > request 806c0c0 from 127.0.0.1 >> > port_dissociate: No such file or directory >> > port_dissociate: No such file or directory >> > port_dissociate: No such file or directory >> > FAILED >> > >> > ----- >> > >> > I have no idea if they should all be passing, or if failing is a nice >> > way of saying "this method isn't supported on OpenSolaris". For the >> > record, using memcached does work, I can set and fetch objects... but >> > I'm concerned about the complaints of port_dissociate. >> > >> > Assuming attachments work, I've attached what I've changed against >> > default 1.3b to get this to compile as it is now... if it helps. >> > >> > Thanks in advance for any wisdom, >> > Brett >> > >> > _______________________________________________ >> > Libevent-users mailing list >> > Libevent-users@monkey.org >> > http://monkey.org/mailman/listinfo/libevent-users >> > >> > >> > >> >> > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users From Shanti.Subramanyam at Sun.COM Wed Jun 6 14:56:47 2007 From: Shanti.Subramanyam at Sun.COM (Shanti Subramanyam - PAE) Date: Wed Jun 6 14:56:54 2007 Subject: [Libevent-users] libevent on OpenSolaris with GCC --- port_dissociate: No such file or directory In-Reply-To: <850f7cbe0706011443h5d48aca2m33d310c8eaad7f93@mail.gmail.com> References: <850f7cbe0706011443h5d48aca2m33d310c8eaad7f93@mail.gmail.com> Message-ID: <4667036F.4050902@Sun.COM> Niels Provos wrote: > I don't have access to Solaris. The only way this can be fixed is by > people running Solaris to send patches. > The patches were sent a while ago by Emil Mikulec on 1/2/07. See http://monkeymail.org/archives/libevent-users/2007-January/000444.html Shanti > Niels. > > On 6/1/07, Brett Hoerner wrote: >> Thanks, that killed the specific complaint/error, but do I want to >> disable event ports? Isn't that Solaris' most fancy event system? >> And should I worry about the evhttp_parse_request_line lines? >> >> Sorry for being useless here. :( >> >> --- >> >> Running tests: >> KQUEUE >> Skipping test >> DEVPOLL >> test-eof: OKAY >> test-weof: OKAY >> test-time: OKAY >> regress: [warn] evhttp_parse_request_line: bad method GET /test >> HTTP/1.1 on request 8072028 from 127.0.0.1 >> FAILED >> POLL >> test-eof: OKAY >> test-weof: OKAY >> test-time: OKAY >> regress: [warn] evhttp_parse_request_line: bad method GET /test >> HTTP/1.1 on request 806b218 from 127.0.0.1 >> FAILED >> SELECT >> test-eof: OKAY >> test-weof: OKAY >> test-time: OKAY >> regress: [warn] evhttp_parse_request_line: bad method GET /test >> HTTP/1.1 on request 806c220 from 127.0.0.1 >> FAILED >> RTSIG >> Skipping test >> EPOLL >> Skipping test >> >> --- >> >> Thanks, >> Brett >> >> >> >> On 6/1/07, Andrew Danforth wrote: >> > Try setting EVENT_NOEVPORT to 1 in your environment (export >> > EVENT_NOEVPORT=1). That will disable the Solaris event ports code >> which is >> > probably what is causing your port_disassociate errors. Can't say >> whether >> > or not it will uncover other problems, though. >> > >> > A >> > >> > On 6/1/07, Brett Hoerner wrote: >> > > >> > > I'm having a tough time compiling libevent-1.3b on OpenSolaris. I >> > > followed a bunch of clues from this list and others including: >> > > >> > > Replace all usages of 'u_int*_t' with 'uint*_t'. >> > > Replace '__inline' with 'inline' >> > > Run configure with LDFLAGS="-lnsl -lresolv" >> > > >> > > I also used someones' Solaris patch that added some includes in >> > > desperation (all in my diff). >> > > >> > > I'm able to compile it now, but when I run the tests or when I >> compile >> > > memcached against it and make use of memcached, I get the following >> > > error on each event (I guess): >> > > >> > > port_dissociate: No such file or directory >> > > >> > > Google tells me nothing. :( >> > > >> > > This is the output of my the libevent test.sh: >> > > >> > > ----- >> > > >> > > Running tests: >> > > KQUEUE >> > > test-eof: port_dissociate: No such file or directory >> > > port_dissociate: No such file or directory >> > > OKAY >> > > test-weof: port_dissociate: No such file or directory >> > > port_dissociate: No such file or directory >> > > OKAY >> > > test-time: OKAY >> > > regress: port_dissociate: No such file or directory >> > > port_dissociate: No such file or directory >> > > [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on >> > > request 806c0c0 from 127.0.0.1 >> > > port_dissociate: No such file or directory >> > > port_dissociate: No such file or directory >> > > port_dissociate: No such file or directory >> > > FAILED >> > > DEVPOLL >> > > test-eof: port_dissociate: No such file or directory >> > > port_dissociate: No such file or directory >> > > OKAY >> > > test-weof: port_dissociate: No such file or directory >> > > port_dissociate: No such file or directory >> > > OKAY >> > > test-time: OKAY >> > > regress: port_dissociate: No such file or directory >> > > port_dissociate: No such file or directory >> > > [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on >> > > request 806c0c0 from 127.0.0.1 >> > > port_dissociate: No such file or directory >> > > port_dissociate: No such file or directory >> > > port_dissociate: No such file or directory >> > > FAILED >> > > POLL >> > > test-eof: port_dissociate: No such file or directory >> > > port_dissociate: No such file or directory >> > > OKAY >> > > test-weof: port_dissociate: No such file or directory >> > > port_dissociate: No such file or directory >> > > OKAY >> > > test-time: OKAY >> > > regress: port_dissociate: No such file or directory >> > > port_dissociate: No such file or directory >> > > [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on >> > > request 806c0c0 from 127.0.0.1 >> > > port_dissociate: No such file or directory >> > > port_dissociate: No such file or directory >> > > port_dissociate: No such file or directory >> > > FAILED >> > > SELECT >> > > test-eof: port_dissociate: No such file or directory >> > > port_dissociate: No such file or directory >> > > OKAY >> > > test-weof: port_dissociate: No such file or directory >> > > port_dissociate: No such file or directory >> > > OKAY >> > > test-time: OKAY >> > > regress: port_dissociate: No such file or directory >> > > port_dissociate: No such file or directory >> > > [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on >> > > request 806c0c0 from 127.0.0.1 >> > > port_dissociate: No such file or directory >> > > port_dissociate: No such file or directory >> > > port_dissociate: No such file or directory >> > > FAILED >> > > RTSIG >> > > test-eof: port_dissociate: No such file or directory >> > > port_dissociate: No such file or directory >> > > OKAY >> > > test-weof: port_dissociate: No such file or directory >> > > port_dissociate: No such file or directory >> > > OKAY >> > > test-time: OKAY >> > > regress: port_dissociate: No such file or directory >> > > port_dissociate: No such file or directory >> > > [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on >> > > request 806c0c0 from 127.0.0.1 >> > > port_dissociate: No such file or directory >> > > port_dissociate: No such file or directory >> > > port_dissociate: No such file or directory >> > > FAILED >> > > EPOLL >> > > test-eof: port_dissociate: No such file or directory >> > > port_dissociate: No such file or directory >> > > OKAY >> > > test-weof: port_dissociate: No such file or directory >> > > port_dissociate: No such file or directory >> > > OKAY >> > > test-time: OKAY >> > > regress: port_dissociate: No such file or directory >> > > port_dissociate: No such file or directory >> > > [warn] evhttp_parse_request_line: bad method GET /test HTTP/1.1 on >> > > request 806c0c0 from 127.0.0.1 >> > > port_dissociate: No such file or directory >> > > port_dissociate: No such file or directory >> > > port_dissociate: No such file or directory >> > > FAILED >> > > >> > > ----- >> > > >> > > I have no idea if they should all be passing, or if failing is a nice >> > > way of saying "this method isn't supported on OpenSolaris". For the >> > > record, using memcached does work, I can set and fetch objects... but >> > > I'm concerned about the complaints of port_dissociate. >> > > >> > > Assuming attachments work, I've attached what I've changed against >> > > default 1.3b to get this to compile as it is now... if it helps. >> > > >> > > Thanks in advance for any wisdom, >> > > Brett >> > > >> > > _______________________________________________ >> > > Libevent-users mailing list >> > > Libevent-users@monkey.org >> > > http://monkey.org/mailman/listinfo/libevent-users >> > > >> > > >> > > >> > >> > >> _______________________________________________ >> Libevent-users mailing list >> Libevent-users@monkey.org >> http://monkey.org/mailman/listinfo/libevent-users >> >> > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users From lcoquelle at gmail.com Thu Jun 7 04:02:37 2007 From: lcoquelle at gmail.com (Ludovic Coquelle) Date: Thu Jun 7 04:02:49 2007 Subject: [Libevent-users] event loop stop the other threads Message-ID: Hi, I use libevent through the libevent-python wrapper. If it is not the relevant mailing list to ask, please point me to the right place ;) I wanted to write an event loop, running in its own thread, while another thread can do something else. Whatever I've tried, the first call to 'dispatch' block all the others threads (from what I understand). I wrote something like: def evhello(obj, name): # dummy callback: print hello every second print "hello", name if obj: obj.addToLoop(timeout=1) def evstart(name, next=None): evB = libevent.EventBase() # new base for each thread event = libevent.createTimer(lambda fd, events, obj: evhello(obj, name)) event.setEventBase(evB) event.addToLoop(timeout=1) evB.dispatch() t0 = threading.Thread(target=evhello, args=(None, 'toto')) t1 = threading.Thread(target=evstart, args=('toto',)) t2 = threading.Thread(target=evstart, args=('titi',)) t0.start() time.sleep(3) # t0 is effectively running ... t1.start() time.sleep(3) # t1 event loop is running ... but t0 STOPed!!! t2.start() # ... never reach Anybody has a clue on the problem? Is it normal behaviour? Am I doing something wrong? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20070607/8282c3c8/attachment-0001.htm From lcoquelle at gmail.com Thu Jun 7 20:09:45 2007 From: lcoquelle at gmail.com (Ludovic Coquelle) Date: Thu Jun 7 20:09:48 2007 Subject: [Libevent-users] event loop stop the other threads In-Reply-To: <1181236518.6623.1.camel@localhost.localdomain> References: <1181236518.6623.1.camel@localhost.localdomain> Message-ID: Thank for the reply. I have no idea about the behaviour regarding the GIL. But I found that my problem is due to the python wrapper: this is not a bug but it cannot allow threading. What happens is that the python 'dispatch' call the underlying C 'dispatch' (of course) in one python thread. But doing that, python do not control any more this thread, and thus the interpreter is blocked by this call. If I add a timer event in the loop with a callback doing nothing (createTimer(lambda fd,evt,obj: sleep(0)).addToLoop(timeout=0)), the C code call back the python code and the other trheads can be executed ... but why use event if there is a loop on null timer doing nothing!?! So, if there is nothing that can be made in the wrapper for that (I have absolutely no idea), I guess I have to discard either threading either libevent of my program. Which lead me to another question about architecture design. My first (libevent) thread is a socket server, getting requests from all clients, and putting them in a queue. My second thread take request one by one, processes it, and create a reply that it put in a queue used by the first thread. I wanted 2 threads (or 2 thread pool) because the application logic of the second thread imply accessing the DB and doing a fair bit of computation that is not easy to split in events in such a way that we can ensure the response time. If I give up the threading, I could have the same model using processes, but then I need a communication channel between the 2 processes. What can be used which would be efficient? UNIX socket? mkfifo? My other alternative is to replace libevent by the twisted framework which allow an event based server model, but threading for non asynchronous calls. Any comments? On 6/8/07, Ka-Hing Cheung wrote: > > On Thu, 2007-06-07 at 16:02 +0800, Ludovic Coquelle wrote: > > Hi, > > > > I use libevent through the libevent-python wrapper. > > If it is not the relevant mailing list to ask, please point me to the > > right place ;) > > > > I wanted to write an event loop, running in its own thread, while > > another thread can do something else. > > Whatever I've tried, the first call to 'dispatch' block all the others > > threads (from what I understand). > > I wrote something like: > > > > def evhello(obj, name): > > # dummy callback: print hello every second > > print "hello", name > > if obj: > > obj.addToLoop(timeout=1) > > > > def evstart(name, next=None): > > evB = libevent.EventBase() # new base for each thread > > event = libevent.createTimer(lambda fd, events, obj: evhello(obj, > > name)) > > event.setEventBase(evB) > > event.addToLoop(timeout=1) > > evB.dispatch() > > Does dispatch() here give up the global interpreter lock? > > -khc > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20070608/7c1c7ae0/attachment.htm From lcoquelle at gmail.com Thu Jun 7 21:01:58 2007 From: lcoquelle at gmail.com (Ludovic Coquelle) Date: Thu Jun 7 21:02:02 2007 Subject: [Libevent-users] event loop stop the other threads In-Reply-To: <1181263894.25754.2.camel@localhost.localdomain> References: <1181236518.6623.1.camel@localhost.localdomain> <1181263894.25754.2.camel@localhost.localdomain> Message-ID: On 6/8/07, Ka-Hing Cheung wrote: > > On Fri, 2007-06-08 at 08:09 +0800, Ludovic Coquelle wrote: > > Thank for the reply. > > I have no idea about the behaviour regarding the GIL. > > > > But I found that my problem is due to the python wrapper: this is not > > a bug but it cannot allow threading. > > What happens is that the python 'dispatch' call the underlying C > > 'dispatch' (of course) in one python thread. But doing that, python do > > not control any more this thread, and thus the interpreter is blocked > > by this call. > > If I add a timer event in the loop with a callback doing nothing > > (createTimer(lambda fd,evt,obj: sleep(0)).addToLoop(timeout=0)), the C > > code call back the python code and the other trheads can be > > executed ... but why use event if there is a loop on null timer doing > > nothing!?! > > It sounds like this is a bug in the wrapper. I am no python expert, but > I think the wrapper should give up the GIL before calling dispatch and > grab it again before it calls back into python. Probably something like that. But it's not that easy, because it has to release the GIL before dispatch, but dispatch itself will call other python codes which should grab it before execution and release it before going back to dispatch ... but same for me: not a python expert! -khc > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20070608/9d0e3645/attachment.htm From liusifan at gmail.com Fri Jun 8 09:39:21 2007 From: liusifan at gmail.com (liusifan) Date: Fri Jun 8 09:39:30 2007 Subject: [Libevent-users] Threading support question References: <34394a3a0706061124r29c9ab5cu171e0bc575f26f6f@mail.gmail.com> Message-ID: <200706082139146565761@gmail.com> SGksIFBhdHJpY2sgQ2xvY2hlc3kNCg0KSSBndWVzcyB5b3UgbmVlZCBhIGhhbGYtYXluYy9oYWxm LXN5bmMgdGhyZWFkIHBvb2wuDQpUaGUgbWFpbiBldmVudCBsb29wIHRocmVhZCAoaGFsZi1hc3lu YykgImhhbmRsZXMgYWxsIHRoZSBhY2NlcHRzIiwNCmFuZCB0aGUgInR3byBvdGhlciB0eXBlcyBv ZiB0aHJlYWRzIiAoaGFsZi1zeW5jKSBhcmUgaW4gY2hhcmdlIG9mIGF1dGhlbnRpY2F0aW5nLg0K DQpJZiBzbywgaSBzdWdnZXN0IHlvdSB0byB0YWtlIGEgbG9vayBmb3IgdGhlIFNQU2VydmVyIC4N Cg0KPiBTUFNlcnZlciBpcyBhIHNlcnZlciBmcmFtZXdvcmssIGl0IGltcGxlbWVudHM6DQo+IDEu QW4gQWNjZXB0ZXIgZm9yIFRDUCBTZXJ2ZXINCj4gMi5BbiBhc3luY2hyb25vdXMgbGF5ZXIuIEl0 IGhhcyBvbmx5IG9uZSB0aHJlYWQgKCBldmVudCBsb29wIHRocmVhZCApLA0KPiAzLkEgc3luY2hy b25vdXMgbGF5ZXIuIEl0IGhhcyBtdWx0aXBsZSB0aHJlYWRzLg0KPiA0LkEgcXVldWUgYmV0d2Vl biBhc3luY2hyb25vdXMgbGF5ZXIgYW5kIHN5bmNocm9ub3VzIGxheWVyLg0KDQpodHRwOi8vY29k ZS5nb29nbGUuY29tL3Avc3BzZXJ2ZXIvDQpodHRwOi8vc3BzZXJ2ZXIuZ29vZ2xlY29kZS5jb20v ZmlsZXMvc3BzZXJ2ZXItMC4zLnNyYy50YXIuZ3oJDQoNCg0KQmVzdCByZWdhcmRzo6wNCg0KbGl1 c2lmYW4NCjIwMDctMDYtMDgNCg0KPj4+SGVyZSdzIGEgcXVpY2sgc3lub3BzaXMgZm9yIHRob3Nl IHdobyBkb24ndCB3YW50IHRvIHJlYWQgdGhlIHdob2xlDQo+ZXhwbGFuYXRpb24gOikgSXMgaXQg cG9zc2libGUgdG8gY3JlYXRlIGV2ZW50cyBpbiB0aHJlYWRzIHRoYXQgd2lsbA0KPmZpcmUgaW4g dGhlIG1haW4gdGhyZWFkIGlmIHRoZSBhY2Nlc3MgdG8gZXZlbnRfc2V0IGlzIG11dHVhbGx5DQo+ ZXhjbHVzaXZlPw0KPg0KPkxvbmdlciBleHBsYW5hdGlvbjoNCj5BZnRlciBJIGFscmVhZHkgaW1w bGVtZW50ZWQgYSBtdWx0aXRocmVhZGVkIHNlcnZlciBiYXNlZCBvbiBsaWJldmVudCwNCj5JIHNh dyBTdGV2ZW4ncyBtZXNzYWdlIGFib3V0IHRoZSB0aHJlYWRpbmcgc3VwcG9ydC4gSSBiYXNpY2Fs bHkgaGF2ZQ0KPm9uZSB0aHJlYWQgd2hpY2ggZG9lcyBhbGwgdGhlIEkvTywgdHdvIG90aGVyIHR5 cGVzIG9mIHRocmVhZHMuDQo+DQo+VGhlIGZpcnN0IGhhbmRsZXMgYWxsIHRoZSBhY2NlcHRzIGFu ZCBzZW5kcyBhIHdlbGNvbWUgbWVzc2FnZSB0byBlYWNoDQo+bmV3IHRocmVhZCAodXNpbmcgbGli ZXZlbnQgaWYgdGhlIGNhbGwgdG8gd3JpdGUoKSBkb2Vzbid0IHdyaXRlIGFsbA0KPnRoZSBieXRl cykuIFRoZSBzZWNvbmQgaXMgYWN0dWFsbHkgYSBncm91cCBvZiB0aHJlYWRzIHdoaWNoIGFyZSBp bg0KPmNoYXJnZSBvZiBhdXRoZW50aWNhdGluZy4NCj4NCj5JIGhhZCBwbGFubmVkIG9uIGFsbCB0 aGUgdGhyZWFkcyBiZWluZyBhYmxlIHRvIGJlIGFibGUgdG8gY3JlYXRlIG5ldw0KPndyaXRlIGV2 ZW50cyB1c2luZyBsaWJldmVudCwgc2luY2UgdGhlIGFjY2VwdCgpaW5nIHRocmVhZHMgbmVlZCB0 bw0KPnNlbmQgdGhlIHByb3RvY29sICJ3ZWxjb21lIiBhbmQgYWxzbyBjcmVhdGUgYSByZWFkIGV2 ZW50IGZvciB3aGVuIGRhdGENCj5hcnJpdmVzLCBhbmQgdGhlIGF1dGhlbnRpY2F0aW9uIHRocmVh ZHMgbmVlZCB0byBzZW5kIGJhY2sgdG8gdGhlDQo+Y2xpZW50IHdoZXRoZXIgdGhleSBhdXRoZW50 aWNhdGVkIG9yIG5vdC4NCj4NCj5Ib3dldmVyLCBiZWZvcmUgaGF2aW5nIHNlZW4gdGhpcyBJIGlt cGxlbWVudGVkIGl0LCBhbmQgdGhlIGV2ZW50X3NldA0KPmluIHRoZSBhY2NlcHQoKSB0aHJlYWQg aXMgY3JlYXRpbmcgYW4gZXZlbnQgdGhhdCBpcyBmaXJlZCBpbiB0aGUgbWFpbg0KPnRocmVhZHMg ZXZlbnRfZGlzcGF0Y2goKS4gU28sIGlzIGl0IG9rYXkgdG8gY29udGludWUgb24gdGhpcyBwYXRo IGlmIEkNCj5hc3N1cmUgdGhlIGFjY2VzcyBvZiB0aGUgbGliZXZlbnQgb2JqZWN0cyBhcmUgbXV0 dWFsbHkgZXhjbHVzaXZlPw0KPg0KPlRoYW5rcywNCj4tUGF0cmljaw0KPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+TGliZXZlbnQtdXNlcnMgbWFpbGlu ZyBsaXN0DQo+TGliZXZlbnQtdXNlcnNAbW9ua2V5Lm9yZw0KPmh0dHA6Ly9tb25rZXkub3JnL21h aWxtYW4vbGlzdGluZm8vbGliZXZlbnQtdXNlcnMNCgkJCQ0KDQo= From pcloches at gmail.com Fri Jun 8 19:15:22 2007 From: pcloches at gmail.com (Patrick Clochesy) Date: Fri Jun 8 19:15:29 2007 Subject: [Libevent-users] Threading support question In-Reply-To: <200706082139146565761@gmail.com> References: <34394a3a0706061124r29c9ab5cu171e0bc575f26f6f@mail.gmail.com> <200706082139146565761@gmail.com> Message-ID: <34394a3a0706081615oa2394e7ta66d11746a64a072@mail.gmail.com> Thanks. I actually found SPServer shortly after I took a look at this, and it helped me out a great bit. One thing I noticed though, was that its event queue for the threads uses a socketpair for waking up the queue. I implemented it using pthread_cond_wait and a lock it runs about 3 times faster. Stephen, if you'd like the code (not hat you couldn't figure it out, but it took me some debugging to figure out the "proper" way to use pthread_cond_wait for event queues, drop me a line. Thanks for the great work! Thanks, -Patrick On 08/06/07, liusifan wrote: > Hi, Patrick Clochesy > > I guess you need a half-aync/half-sync thread pool. > The main event loop thread (half-async) "handles all the accepts", > and the "two other types of threads" (half-sync) are in charge of authenticating. > > If so, i suggest you to take a look for the SPServer . > > > SPServer is a server framework, it implements: > > 1.An Accepter for TCP Server > > 2.An asynchronous layer. It has only one thread ( event loop thread ), > > 3.A synchronous layer. It has multiple threads. > > 4.A queue between asynchronous layer and synchronous layer. > > http://code.google.com/p/spserver/ > http://spserver.googlecode.com/files/spserver-0.3.src.tar.gz > > > Best regards? > > liusifan > 2007-06-08 > > >>>Here's a quick synopsis for those who don't want to read the whole > >explanation :) Is it possible to create events in threads that will > >fire in the main thread if the access to event_set is mutually > >exclusive? > > > >Longer explanation: > >After I already implemented a multithreaded server based on libevent, > >I saw Steven's message about the threading support. I basically have > >one thread which does all the I/O, two other types of threads. > > > >The first handles all the accepts and sends a welcome message to each > >new thread (using libevent if the call to write() doesn't write all > >the bytes). The second is actually a group of threads which are in > >charge of authenticating. > > > >I had planned on all the threads being able to be able to create new > >write events using libevent, since the accept()ing threads need to > >send the protocol "welcome" and also create a read event for when data > >arrives, and the authentication threads need to send back to the > >client whether they authenticated or not. > > > >However, before having seen this I implemented it, and the event_set > >in the accept() thread is creating an event that is fired in the main > >threads event_dispatch(). So, is it okay to continue on this path if I > >assure the access of the libevent objects are mutually exclusive? > > > >Thanks, > >-Patrick > >_______________________________________________ > >Libevent-users mailing list > >Libevent-users@monkey.org > >http://monkey.org/mailman/listinfo/libevent-users > > > From liusifan at gmail.com Sat Jun 9 01:28:03 2007 From: liusifan at gmail.com (liusifan) Date: Sat Jun 9 01:28:14 2007 Subject: [Libevent-users] Threading support question References: <34394a3a0706061124r29c9ab5cu171e0bc575f26f6f@mail.gmail.com>, <200706082139146565761@gmail.com>, <34394a3a0706081615oa2394e7ta66d11746a64a072@mail.gmail.com> Message-ID: <200706091328003590551@gmail.com> SGksIFBhdHJpY2sgQ2xvY2hlc3kNCg0KPk9uZSB0aGluZyBJIG5vdGljZWQgdGhvdWdoLCB3YXMg dGhhdCBpdHMgZXZlbnQgcXVldWUgZm9yIHRoZSB0aHJlYWRzIA0KPnVzZXMgYSBzb2NrZXRwYWly IGZvciB3YWtpbmcgdXAgdGhlIHF1ZXVlLiANCg0KQXJlIHlvdSB0YWxraW5nIGFib3V0IFNQX0V4 ZWN1dG9yIKO/DQpGb3IgdXNpbmcgbXNnZXZlbnRfcXVldWUoc29ja2V0cGFpcikgYmVjYXVzZSBp IGRvbid0IHdhbnQgdG8gd3JpdGUNCm1vcmUgc291cmNlIGNvZGUsIHRoZSBtc2dldmVudF9xdWV1 ZSBjYW4ganVzdCBmaXggdGhlIHJlcXVpcmVtZW50Lg0KDQo+SSBpbXBsZW1lbnRlZCBpdCB1c2lu ZyBwdGhyZWFkX2NvbmRfd2FpdCBhbmQgYSBsb2NrIGl0IHJ1bnMgYWJvdXQgMyB0aW1lcyBmYXN0 ZXIuDQo+DQoNCkRvIHlvdSBtZWFuIHlvdSBoYXZlIG1vZGlmaWVkIHRoZSBTUF9FeGVjdXRvciBh bmQgZG8gYSBiZW5jaG1hcmsgPw0KSWYgc28sIGkgYW0gdmVyeSBnbGFkIHRvIHNlZSBpdC4gSWYg eW91IGNhbiBwcm92aWRlIHRoZSBzb3VyY2UgY29kZSwgDQppIHdpbGwgY29tbWl0IGl0IHRvIHN2 bi4gVGhhbmtzLg0KDQpCZXN0IHJlZ2FyZHOjrA0KDQpsaXVzaWZhbg0KMjAwNy0wNi0wOQ0K From liusifan at gmail.com Mon Jun 11 00:11:06 2007 From: liusifan at gmail.com (lau stephen) Date: Mon Jun 11 00:11:09 2007 Subject: [Libevent-users] libevent on OpenSolaris with GCC --- port_dissociate: No such file or directory In-Reply-To: <850f7cbe0706011443h5d48aca2m33d310c8eaad7f93@mail.gmail.com> References: <850f7cbe0706011443h5d48aca2m33d310c8eaad7f93@mail.gmail.com> Message-ID: Maybe you can use this: http://en.unix-center.net/?page_id=2 2007/6/2, Niels Provos : > > I don't have access to Solaris. The only way this can be fixed is by > people running Solaris to send patches. > > Niels. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20070611/a4016c2d/attachment.htm From mat at oxado.com Mon Jun 11 05:54:50 2007 From: mat at oxado.com (Matthieu PATOU) Date: Mon Jun 11 05:55:04 2007 Subject: [Libevent-users] libevent on FREEBSD Message-ID: <466D1BEA.5080007@oxado.com> Dear list, i'm working on a partial C implementation of the memcache PERL client. The part i rewrote in C was a big loop around a select that handled read and write from the various memcached server. I was expecting the libevent code to be quicker or least not slower than a standard select call. With linux, this assumption seems true, but under Freebsd it seems false. Tracing the syscall with strace shows that clock_gettime is called on average 3 times between a read or write event. % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 50.35 1.904478 43 44722 clock_gettime 22.20 0.839851 62 13623 read I'm wondering if there is a solution to reduce the number of calls to clock_gettime or a way to make them less costly. If not maybe i should do the loop around a select in C like it was done in PERL. Matthieu From adrian at creative.net.au Mon Jun 11 07:32:17 2007 From: adrian at creative.net.au (Adrian Chadd) Date: Mon Jun 11 07:31:57 2007 Subject: [Libevent-users] libevent on FREEBSD In-Reply-To: <466D1BEA.5080007@oxado.com> References: <466D1BEA.5080007@oxado.com> Message-ID: <20070611113217.GA2455@skywalker.creative.net.au> On Mon, Jun 11, 2007, Matthieu PATOU wrote: > Dear list, > > i'm working on a partial C implementation of the memcache PERL client. > The part i rewrote in C was a big loop around a select that handled read > and write from the various memcached server. > > I was expecting the libevent code to be quicker or least not slower than a > standard select call. > With linux, this assumption seems true, but under Freebsd it seems false. > > Tracing the syscall with strace shows that clock_gettime is called on > average 3 times between a read or write event. Its known that FreeBSD's gettimeofday() call isn't going to be as fast as the Linux version (doesn't the Linux version do some hackery to stay in userspace?) but its occuring during every event_add() for what I can only assume is a second-resolution timeout timer. I'm not uptodate on the libevent internals - perhaps someone else could take a look at how feasable it'd be to store a copy of the gettimeofday() results at the beginning of each trip through the event loop (per thread!) and use that value for ev_add(). (Squid does this to get around the slowness of doing massive amounts of gettimeofday() calls for this precise reason.) 2c, Adrian From anight at eyelinkmedia.com Tue Jun 12 08:26:49 2007 From: anight at eyelinkmedia.com (Andrei Nigmatulin) Date: Tue Jun 12 09:26:41 2007 Subject: [Libevent-users] Solaris fixes Message-ID: <200706121626.50035.anight@eyelinkmedia.com> Hello The diff attached is targeted to Solaris users, it solves several issues: - "__inline" should not be used because AC_C_INLINE will provide appropriate substitution for "inline", if necessary. In particular, Sun C compiler does not recognize __inline. - added missing evport_dealloc() - added missing -lresolv check. Without one libtool does not add libresolv into dependency_libs list in libevent.la. - devpoll.c compilation fixes -- Andrei Nigmatulin GPG PUB KEY 6449830D Now I lay me down to sleep(3) Pray the OS my core to keep If I die before I wake Pray the Disk my core to take -------------- next part -------------- A non-text attachment was scrubbed... Name: libevent-solaris_fixes.diff Type: text/x-diff Size: 2889 bytes Desc: not available Url : http://monkeymail.org/archives/libevent-users/attachments/20070612/561690ed/libevent-solaris_fixes.bin From anight at eyelinkmedia.com Tue Jun 12 19:33:27 2007 From: anight at eyelinkmedia.com (Andrei Nigmatulin) Date: Tue Jun 12 19:33:15 2007 Subject: [Libevent-users] bug in event_base_free() Message-ID: <200706130333.27677.anight@eyelinkmedia.com> Hello, list Please consider my application: 1. There is one process that always in event loop (master process). 2. By some event it forks and create "child" process, that call event_exit_loop() and after event_loop() exits it try to clean up everything associated with libevent. 3. For this purpose child call event_base_free(), but it have to remove all events that was added by parent before fork happened. Otherwise it will be hit by assert(TAILQ_EMPTY(&base->eventqueue)). 4. With poll or select methods there no problems with deleting events at this point. 5. But with epoll, kqueue or event ports methods the child and the parent shares *same* event device and set of file descriptors after fork(). So if child call event_del() on every event that was added before in parent, events are also deleted from parent's device (actually, the same device), which is absolutely not what I want. Thus, there is only one way to deal with it: child must not call event_base_free() and must live with opened event device. Attached diff provides a fix for this situation. I believe process must not check if base->eventqueue and other queues are empty. Calling evsel->dealloc() is enough to remove all events. -- Andrei Nigmatulin GPG PUB KEY 6449830D Now I lay me down to sleep(3) Pray the OS my core to keep If I die before I wake Pray the Disk my core to take -------------- next part -------------- A non-text attachment was scrubbed... Name: libevent-base_free.diff Type: text/x-diff Size: 632 bytes Desc: not available Url : http://monkeymail.org/archives/libevent-users/attachments/20070613/403e0612/libevent-base_free.bin From harningt at gmail.com Tue Jun 12 22:49:25 2007 From: harningt at gmail.com (Thomas Harning Jr.) Date: Tue Jun 12 22:59:30 2007 Subject: [Libevent-users] Segfault when attempting to add more than ~1012 events Message-ID: I've been testing out a Lua binding to libevent ( http://luaforge.net/projects/luaevent/) and found a strange segfault & memory access error in libevent when adding ~1012 events... I wrote a really simple test case and have included output... I'm not sure on the policy for attachments for this mailing list, so here's links to the code/logs Source code http://rafb.net/p/RYHZ1I68.html Log: http://rafb.net/p/34ZA4i22.html -- Thomas Harning Jr. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20070612/db89469a/attachment.htm From harningt at gmail.com Tue Jun 12 23:11:52 2007 From: harningt at gmail.com (Thomas Harning Jr.) Date: Tue Jun 12 23:11:56 2007 Subject: [Libevent-users] Segfault when attempting to add more than ~1012 events In-Reply-To: <20070613030551.GB19754@wilbur.25thandClement.com> References: <20070613030551.GB19754@wilbur.25thandClement.com> Message-ID: On 6/12/07, William Ahern wrote: > On Tue, Jun 12, 2007 at 10:49:25PM -0400, Thomas Harning Jr. wrote: ... > > Log: > > http://rafb.net/p/34ZA4i22.html > > Is libevent using select(2)? > > This sounds suspicously like an issue with the size of the fd_set > structure/array. 1012 is about when C-Ares blows up, an async DNS library > which takes fd_set's as parameters to its churn function. > Nope.. its using epoll... @ line ~14 in the log it shows that its calling into epoll (+ when I ran `strace` it was using epoll...) -- Thomas Harning Jr. From provos at citi.umich.edu Thu Jun 14 02:18:01 2007 From: provos at citi.umich.edu (Niels Provos) Date: Thu Jun 14 02:18:09 2007 Subject: [Libevent-users] Segfault when attempting to add more than ~1012 events In-Reply-To: References: Message-ID: <850f7cbe0706132318n1fa8a067p2bab44f91f47b192@mail.gmail.com> What happens when you run the benchmark program (bench) with -n 2000? Niels. On 6/12/07, Thomas Harning Jr. wrote: > I've been testing out a Lua binding to libevent > (http://luaforge.net/projects/luaevent/) and found a > strange segfault & memory access error in libevent when adding ~1012 > events... > > I wrote a really simple test case and have included output... > > I'm not sure on the policy for attachments for this mailing list, so here's > links to the code/logs > Source code > http://rafb.net/p/RYHZ1I68.html > Log: > http://rafb.net/p/34ZA4i22.html > > -- > Thomas Harning Jr. > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users > > From harningt at gmail.com Thu Jun 14 06:52:58 2007 From: harningt at gmail.com (Thomas Harning Jr.) Date: Thu Jun 14 06:53:03 2007 Subject: [Libevent-users] Segfault when attempting to add more than ~1012 events In-Reply-To: <850f7cbe0706132318n1fa8a067p2bab44f91f47b192@mail.gmail.com> References: <850f7cbe0706132318n1fa8a067p2bab44f91f47b192@mail.gmail.com> Message-ID: On 6/14/07, Niels Provos wrote: > What happens when you run the benchmark program (bench) with -n 2000? > > Niels. > Hrm... states that setrlimit is not permitted by my user... As root.. nothing bad happens... Not sure what the issue is then..... -- Thomas Harning Jr. From jan at kneschke.de Thu Jun 14 11:04:40 2007 From: jan at kneschke.de (Jan Kneschke) Date: Thu Jun 14 11:33:27 2007 Subject: [Libevent-users] compile patches for non-gcc Message-ID: <46715908.5050309@kneschke.de> Hi, I'm porting http://jan.kneschke.de/projects/mysql/mysql-proxy from a simple poll() to libevent-1.3b and ran a compile-run on the MySQL build-farm. We are using the native compilers if possible to sort out possible user problems on our side. For libevent we had some problems on AIX and Solaris which got fixed in the attached patches. HPUX is still open as it is missing a definition for "struct sockaddr_storage". This way I get a clean compile on: - solaris 8-10 (x86|x86_64|sparc32|sparc64) - AIX 5.2 (ppc32|ppc64) - Linux (gcc 2.95 on SuSE 7.3 up to recent) - FreeBSD - MacOSX 10.3 and later The patches are: libevent-1.3b-aix-clockgettime.diff AIX has clock_gettime(), but only if you #define _XOPEN_SOURCE >= 500. Without it, the defines are invisible which leads to a compile error. Checking if the defines are available fixes it. libevent-1.3b-aix-select.diff sys/select.h is needed for the NFDBITS libevent-1.3b-c99-comments.diff // comments are available in C99 and GCC 3+ only. libevent-1.3b-c99-varargs.diff args... is GCC only, __VAR_ARGS__ is C99 and available on older compilers too. libevent-1.3b-c99-variables.diff in pre-c99 variables have to be defined before code. This affects the compile in gcc-2.95. libevent-1.3b-cflags.diff Setting CFLAGS directly breaks the passing of -m64, -xarch=v9, ... from the command line to get a 64bit compile. Use AM_CFLAGS instead. libevent-1.3b-config-h.diff config.h is needed to get defines right. libevent-1.3b-inline.diff configure checks for the right way to define something 'inline'. Use it. libevent-1.3b-solaris.diff On solaris we need -lresolv and -lnsl for get inet_aton and friends. libevent-1.3b-stdint.diff stdint.h is available on all recent compilers and defines uint8_t and friends which uint8_t is BSD only. The checks in config.h are nice, but aren't propagated to the application which is using event.h. cheers, Jan -- jan: "Gee, Brain^WEric, what'd you wanna do tonight?" eric: Same thing we do everynight: Take over the HelloWorld! -------------- next part -------------- A non-text attachment was scrubbed... Name: libevent-1.3b-aix-clockgettime.diff Type: text/x-patch Size: 564 bytes Desc: not available Url : http://monkeymail.org/archives/libevent-users/attachments/20070614/1eb2d644/libevent-1.3b-aix-clockgettime-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: libevent-1.3b-aix-select.diff Type: text/x-patch Size: 380 bytes Desc: not available Url : http://monkeymail.org/archives/libevent-users/attachments/20070614/1eb2d644/libevent-1.3b-aix-select-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: libevent-1.3b-c99-comments.diff Type: text/x-patch Size: 58372 bytes Desc: not available Url : http://monkeymail.org/archives/libevent-users/attachments/20070614/1eb2d644/libevent-1.3b-c99-comments-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: libevent-1.3b-c99-varargs.diff Type: text/x-patch Size: 804 bytes Desc: not available Url : http://monkeymail.org/archives/libevent-users/attachments/20070614/1eb2d644/libevent-1.3b-c99-varargs-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: libevent-1.3b-c99-variables.diff Type: text/x-patch Size: 1771 bytes Desc: not available Url : http://monkeymail.org/archives/libevent-users/attachments/20070614/1eb2d644/libevent-1.3b-c99-variables-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: libevent-1.3b-cflags.diff Type: text/x-patch Size: 936 bytes Desc: not available Url : http://monkeymail.org/archives/libevent-users/attachments/20070614/1eb2d644/libevent-1.3b-cflags-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: libevent-1.3b-config-h.diff Type: text/x-patch Size: 2674 bytes Desc: not available Url : http://monkeymail.org/archives/libevent-users/attachments/20070614/1eb2d644/libevent-1.3b-config-h-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: libevent-1.3b-inline.diff Type: text/x-patch Size: 855 bytes Desc: not available Url : http://monkeymail.org/archives/libevent-users/attachments/20070614/1eb2d644/libevent-1.3b-inline-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: libevent-1.3b-solaris.diff Type: text/x-patch Size: 728 bytes Desc: not available Url : http://monkeymail.org/archives/libevent-users/attachments/20070614/1eb2d644/libevent-1.3b-solaris-0001.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: libevent-1.3b-stdint.diff Type: text/x-patch Size: 2605 bytes Desc: not available Url : http://monkeymail.org/archives/libevent-users/attachments/20070614/1eb2d644/libevent-1.3b-stdint-0001.bin From colm-libevent at blackstar.co.uk Sat Jun 16 09:34:16 2007 From: colm-libevent at blackstar.co.uk (colm-libevent@blackstar.co.uk) Date: Sat Jun 16 09:40:14 2007 Subject: [Libevent-users] Patches for Cygwin / getaddrinfo Message-ID: <20070616133416.GA4204@sendit.com> Hi, Attahced is a patch against libevent-1.3b for Cygwin - or cases where getaddrinfo() and/or getnameinfo() are not present. The patch addresses 3 issue : 1] compile error in test/regress_http.c when getaddrinfo() is not present. Changed this to use a similar workaround to the one already in http.c. Since this workaround is now used twice I dumped it in a seperate header called fake_getaddrinfo.h 2] a runtime problem with fake_getaddrinfo - worked around by adding an extra port argument to fake_getaddrinfo (not sure if this is the right solution but it worked for me). 3] a runtime problem in cases where getnameinfo() in which we were dropping out of name_from_addr() without doing anything and this was casuing a segfault. Colm -------------- next part -------------- diff -Naur --exclude-from exclude libevent-1.3b_base/fake_getaddrinfo.h libevent-1.3b/fake_getaddrinfo.h --- libevent-1.3b_base/fake_getaddrinfo.h 1970-01-01 00:00:00.000000000 +0000 +++ libevent-1.3b/fake_getaddrinfo.h 2007-06-16 03:32:38.515625000 +0100 @@ -0,0 +1,42 @@ + +struct addrinfo { + int ai_family; + int ai_socktype; + int ai_protocol; + size_t ai_addrlen; + struct sockaddr *ai_addr; + struct addrinfo *ai_next; +}; +static int +fake_getaddrinfo(const char *hostname, struct addrinfo *ai, in_port_t port) +{ + struct hostent *he; + struct in_addr **ap; + struct sockaddr_in *sa_in; + + he = gethostbyname(hostname); + if (!he) + return (-1); + ai->ai_family = he->h_addrtype; + ai->ai_socktype = SOCK_STREAM; + ai->ai_protocol = 0; + //ai->ai_addrlen = he->h_length; + ai->ai_addrlen = sizeof(struct sockaddr_in); + if (NULL == (ai->ai_addr = malloc(ai->ai_addrlen))) + return (-1); + + sa_in = (struct sockaddr_in *)ai->ai_addr; + memset(sa_in, 0, sizeof(struct sockaddr_in)); + sa_in->sin_family = PF_INET; + sa_in->sin_port = htons(port); + ap = (struct in_addr **)he->h_addr_list; + memcpy(&sa_in->sin_addr, *ap, sizeof(struct in_addr)); + + ai->ai_next = NULL; + return (0); +} +static void +fake_freeaddrinfo(struct addrinfo *ai) +{ + free(ai->ai_addr); +} diff -Naur --exclude-from exclude libevent-1.3b_base/http.c libevent-1.3b/http.c --- libevent-1.3b_base/http.c 2007-03-04 04:05:04.000000000 +0000 +++ libevent-1.3b/http.c 2007-06-16 03:45:02.437500000 +0100 @@ -80,36 +80,7 @@ #include "http-internal.h" #ifndef HAVE_GETADDRINFO -struct addrinfo { - int ai_family; - int ai_socktype; - int ai_protocol; - size_t ai_addrlen; - struct sockaddr *ai_addr; - struct addrinfo *ai_next; -}; -static int -fake_getaddrinfo(const char *hostname, struct addrinfo *ai) -{ - struct hostent *he; - he = gethostbyname(hostname); - if (!he) - return (-1); - ai->ai_family = he->h_addrtype; - ai->ai_socktype = SOCK_STREAM; - ai->ai_protocol = 0; - ai->ai_addrlen = he->h_length; - if (NULL == (ai->ai_addr = malloc(ai->ai_addrlen))) - return (-1); - memcpy(ai->ai_addr, &he->h_addr_list[0], ai->ai_addrlen); - ai->ai_next = NULL; - return (0); -} -static void -fake_freeaddrinfo(struct addrinfo *ai) -{ - free(ai->ai_addr); -} +#include "fake_getaddrinfo.h" #endif #ifndef MIN @@ -2190,12 +2161,17 @@ else event_errx(1, "getnameinfo failed: %s", gai_strerror(ni_result)); } - - *phost = ntop; - *pport = strport; #else - // XXXX + char ntop[1025]; + char strport[32]; + struct sockaddr_in *sin = (struct sockaddr_in *)sa; + + snprintf(strport, sizeof(strport), "%d", ntohs(sin->sin_port)); + strcpy(ntop, inet_ntoa(sin->sin_addr)); #endif + + *phost = ntop; + *pport = strport; } /* Either connect or bind */ @@ -2279,7 +2255,8 @@ return (-1); } #else - if (fake_getaddrinfo(address, &ai) < 0) { + memset(&ai, 0, sizeof (ai)); + if (fake_getaddrinfo(address, &ai, port) < 0) { event_warn("fake_getaddrinfo"); return (-1); } diff -Naur --exclude-from exclude libevent-1.3b_base/test/regress_http.c libevent-1.3b/test/regress_http.c --- libevent-1.3b_base/test/regress_http.c 2007-02-16 00:49:03.000000000 +0000 +++ libevent-1.3b/test/regress_http.c 2007-06-16 03:32:33.765625000 +0100 @@ -44,6 +44,7 @@ #include #include #include +#include #endif #include #include @@ -57,6 +58,10 @@ #include "log.h" #include "http-internal.h" +#ifndef HAVE_GETADDRINFO +#include "fake_getaddrinfo.h" +#endif + extern int pair[]; extern int test_ok; @@ -97,9 +102,10 @@ { /* Stupid code for connecting */ struct addrinfo ai, *aitop; - char strport[NI_MAXSERV]; int fd; - + +#ifdef HAVE_GETADDRINFO + char strport[NI_MAXSERV]; memset(&ai, 0, sizeof (ai)); ai.ai_family = AF_INET; ai.ai_socktype = SOCK_STREAM; @@ -108,6 +114,14 @@ event_warn("getaddrinfo"); return (-1); } +#else + memset(&ai, 0, sizeof (ai)); + if (fake_getaddrinfo(address, &ai, port) < 0) { + event_warn("fake_getaddrinfo"); + return (-1); + } + aitop = &ai; +#endif fd = socket(AF_INET, SOCK_STREAM, 0); if (fd == -1) @@ -116,7 +130,11 @@ if (connect(fd, aitop->ai_addr, aitop->ai_addrlen) == -1) event_err(1, "connect failed"); +#ifdef HAVE_GETADDRINFO freeaddrinfo(aitop); +#else + fake_freeaddrinfo(aitop); +#endif return (fd); } From rotaecho at yahoo.com Mon Jun 18 17:18:10 2007 From: rotaecho at yahoo.com (William Pool) Date: Mon Jun 18 18:25:46 2007 Subject: [Libevent-users] Solaris 10 Sun Studio 11 & libevent 1.3b Message-ID: <883874.61090.qm@web32804.mail.mud.yahoo.com> I'm trying to get libevent compiled with Sun Studio 12, but keep running into problems. Below is my compile line / options and the error. Any help would be appreciated. Thanks! Solaris 10 x86 U3 PATH=/opt/yp/bin:/opt/SUNWspro/bin:/opt/sfw/bin:/opt/sfw/sbin:/usr/sfw/bin:/usr/sfw/sbin:/usr/bin:/usr/sbin:/sbin:/usr/ucb:/usr/ccs/bin # Library Link Flags LIBS="-lfasttime" LD_PRELOAD=/usr/lib/libmtmalloc.so LDFLAGS="-L/opt/yp/lib -R/opt/yp/lib -L/opt/sfw/lib -R/opt/sfw/lib -L/usr/sfw/lib -R/usr/sfw/lib -L/usr/lib -R/usr/lib" # Compiler Flags CFLAGS="-fast -m32 -mt -lpthread" CXX=CC CXXFLAGS="-fast -m32 -mt -lpthread" # Include Flags CPPFLAGS="-I/opt/yp/include -I/opt/sfw/include -I/usr/sfw/include" # Export VARS export CFLAGS CXX CXXFLAGS CPPFLAGS LDFLAGS LIBS LD_PRELOAD ./configure --prefix=/opt/yp Configure shows no errors then I run dmake (make or gmake all produce the same) giving no special cc flags also provides the same error. root@ldfs13 # dmake dmake: defaulting to parallel mode. See the man page dmake(1) for more information on setting up the .dmakerc file. dmake all-recursive Making all in . ldfs13 --> 1 job /bin/bash ./libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I. -Icompat -I/opt/yp/include -I/opt/sfw/include -I/usr/sfw/include -fast -m32 -mt -lpthread -c -o event.lo event.c ldfs13 --> 2 jobs /bin/bash ./libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I. -Icompat -I/opt/yp/include -I/opt/sfw/include -I/usr/sfw/include -fast -m32 -mt -lpthread -c -o buffer.lo buffer.c ldfs13 --> Job output /bin/bash ./libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I. -Icompat -I/opt/yp/include -I/opt/sfw/include -I/usr/sfw/include -fast -m32 -mt -lpthread -c -o buffer.lo buffer.c cc -DHAVE_CONFIG_H -I. -I. -I. -Icompat -I/opt/yp/include -I/opt/sfw/include -I/usr/sfw/include -fast -m32 -mt -lpthread -c buffer.c -KPIC -DPIC -o .libs/buffer.o cc -DHAVE_CONFIG_H -I. -I. -I. -Icompat -I/opt/yp/include -I/opt/sfw/include -I/usr/sfw/include -fast -m32 -mt -lpthread -c buffer.c -o buffer.o >/dev/null 2>&1 ldfs13 --> 2 jobs /bin/bash ./libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I. -Icompat -I/opt/yp/include -I/opt/sfw/include -I/usr/sfw/include -fast -m32 -mt -lpthread -c -o evbuffer.lo evbuffer.c ldfs13 --> Job output /bin/bash ./libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I. -Icompat -I/opt/yp/include -I/opt/sfw/include -I/usr/sfw/include -fast -m32 -mt -lpthread -c -o event.lo event.c mkdir .libs cc -DHAVE_CONFIG_H -I. -I. -I. -Icompat -I/opt/yp/include -I/opt/sfw/include -I/usr/sfw/include -fast -m32 -mt -lpthread -c event.c -KPIC -DPIC -o .libs/event.o "event.c", line 168: warning: syntax error: empty declaration "event.c", line 170: warning: syntax error: empty declaration cc -DHAVE_CONFIG_H -I. -I. -I. -Icompat -I/opt/yp/include -I/opt/sfw/include -I/usr/sfw/include -fast -m32 -mt -lpthread -c event.c -o event.o >/dev/null 2>&1 ldfs13 --> 2 jobs /bin/bash ./libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I. -Icompat -I/opt/yp/include -I/opt/sfw/include -I/usr/sfw/include -fast -m32 -mt -lpthread -c -o log.lo log.c ldfs13 --> Job output /bin/bash ./libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I. -Icompat -I/opt/yp/include -I/opt/sfw/include -I/usr/sfw/include -fast -m32 -mt -lpthread -c -o evbuffer.lo evbuffer.c cc -DHAVE_CONFIG_H -I. -I. -I. -Icompat -I/opt/yp/include -I/opt/sfw/include -I/usr/sfw/include -fast -m32 -mt -lpthread -c evbuffer.c -KPIC -DPIC -o .libs/evbuffer.o cc -DHAVE_CONFIG_H -I. -I. -I. -Icompat -I/opt/yp/include -I/opt/sfw/include -I/usr/sfw/include -fast -m32 -mt -lpthread -c evbuffer.c -o evbuffer.o >/dev/null 2>&1 ldfs13 --> 2 jobs /bin/bash ./libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I. -Icompat -I/opt/yp/include -I/opt/sfw/include -I/usr/sfw/include -fast -m32 -mt -lpthread -c -o event_tagging.lo event_tagging.c ldfs13 --> Job output /bin/bash ./libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I. -Icompat -I/opt/yp/include -I/opt/sfw/include -I/usr/sfw/include -fast -m32 -mt -lpthread -c -o event_tagging.lo event_tagging.c cc -DHAVE_CONFIG_H -I. -I. -I. -Icompat -I/opt/yp/include -I/opt/sfw/include -I/usr/sfw/include -fast -m32 -mt -lpthread -c event_tagging.c -KPIC -DPIC -o .libs/event_tagging.o "event_tagging.c", line 153: syntax error before or at: decode_int_internal "event_tagging.c", line 154: warning: old-style declaration or incorrect type for: decode_int_internal cc: acomp failed for event_tagging.c *** Error code 1 dmake: Fatal error: Command failed for target `event_tagging.lo' Current working directory /root/libevent-1.3b Waiting for 1 job to finish ldfs13 --> Job output /bin/bash ./libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I. -Icompat -I/opt/yp/include -I/opt/sfw/include -I/usr/sfw/include -fast -m32 -mt -lpthread -c -o log.lo log.c cc -DHAVE_CONFIG_H -I. -I. -I. -Icompat -I/opt/yp/include -I/opt/sfw/include -I/usr/sfw/include -fast -m32 -mt -lpthread -c log.c -KPIC -DPIC -o .libs/log.o cc -DHAVE_CONFIG_H -I. -I. -I. -Icompat -I/opt/yp/include -I/opt/sfw/include -I/usr/sfw/include -fast -m32 -mt -lpthread -c log.c -o log.o >/dev/null 2>&1 *** Error code 1 The following command caused the error: failcom='exit 1'; \ for f in x $MAKEFLAGS; do \ case $f in \ *=* | --[!k]*);; \ *k*) failcom='fail=yes';; \ esac; \ done; \ dot_seen=no; \ target=`echo all-recursive | sed s/-recursive//`; \ list='. sample test'; for subdir in $list; do \ echo "Making $target in $subdir"; \ if test "$subdir" = "."; then \ dot_seen=yes; \ local_target="$target-am"; \ else \ local_target="$target"; \ fi; \ (cd $subdir && dmake $local_target) \ || eval $failcom; \ done; \ if test "$dot_seen" = "no"; then \ dmake "$target-am" || exit 1; \ fi; test -z "$fail" dmake: Fatal error: Command failed for target `all-recursive' Current working directory /root/libevent-1.3b *** Error code 1 dmake: Fatal error: Command failed for target `all' root@ldfs13 # --------------------------------- Need a vacation? Get great deals to amazing places on Yahoo! Travel. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20070618/0210122b/attachment.htm From slamb at slamb.org Mon Jun 18 18:33:17 2007 From: slamb at slamb.org (Scott Lamb) Date: Mon Jun 18 18:33:48 2007 Subject: [Libevent-users] Solaris 10 Sun Studio 11 & libevent 1.3b In-Reply-To: <883874.61090.qm@web32804.mail.mud.yahoo.com> References: <883874.61090.qm@web32804.mail.mud.yahoo.com> Message-ID: <4677082D.5030804@slamb.org> William Pool wrote: > "event_tagging.c", line 153: syntax error before or at: decode_int_internal > "event_tagging.c", line 154: warning: old-style declaration or incorrect > type for: decode_int_internal I'd guess it's tripping on the "inline": event_tagging.c 152: static int inline 153: decode_int_internal(u_int32_t *pnumber, struct evbuffer *evbuf, int dodrain) 154: { Take a look through the list archives - Jan Kneschke posted a bunch of patches on the 14th for compiling on Solaris, subject line "compile patches for non-gcc". From rotaecho at yahoo.com Mon Jun 18 20:02:48 2007 From: rotaecho at yahoo.com (William Pool) Date: Mon Jun 18 22:36:45 2007 Subject: [Libevent-users] Solaris 10 Sun Studio 11 & libevent 1.3b In-Reply-To: <4677082D.5030804@slamb.org> Message-ID: <484447.88511.qm@web32806.mail.mud.yahoo.com> I'll give it a look, seems like this has been an on-going issue with libevent. Is there going to be a smoother incorporation of these patches to allow smooth compile on other OSes than Linux? -William Scott Lamb wrote: William Pool wrote: > "event_tagging.c", line 153: syntax error before or at: decode_int_internal > "event_tagging.c", line 154: warning: old-style declaration or incorrect > type for: decode_int_internal I'd guess it's tripping on the "inline": event_tagging.c 152: static int inline 153: decode_int_internal(u_int32_t *pnumber, struct evbuffer *evbuf, int dodrain) 154: { Take a look through the list archives - Jan Kneschke posted a bunch of patches on the 14th for compiling on Solaris, subject line "compile patches for non-gcc". --------------------------------- Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://monkeymail.org/archives/libevent-users/attachments/20070618/f4690aef/attachment-0001.htm From provos at citi.umich.edu Sat Jun 30 15:10:22 2007 From: provos at citi.umich.edu (Niels Provos) Date: Sat Jun 30 15:10:29 2007 Subject: [Libevent-users] Solaris 10 Sun Studio 11 & libevent 1.3 In-Reply-To: <484447.88511.qm@web32806.mail.mud.yahoo.com> References: <4677082D.5030804@slamb.org> <484447.88511.qm@web32806.mail.mud.yahoo.com> Message-ID: <850f7cbe0706301210l134aeeb0k4a4a3828bcacbfb@mail.gmail.com> Hi William, please check out the current trunk from subversion and see if it compiles on Solaris. I have committed several fixes that should help, but don't have Solaris accessible myself. If it works, I will cut a new release. Thanks for your patience, work is keeping me incredibly busy, Niels. On 6/18/07, William Pool wrote: > I'll give it a look, seems like this has been an on-going issue with > libevent. > > Is there going to be a smoother incorporation of these patches to allow > smooth compile on other OSes than Linux? > > -William > > Scott Lamb wrote: > William Pool wrote: > > "event_tagging.c", line 153: syntax error before or at: > decode_int_internal > > "event_tagging.c", line 154: warning: old-style declaration or incorrect > > type for: decode_int_internal > > I'd guess it's tripping on the "inline": > > event_tagging.c > 152: static int inline > 153: decode_int_internal(u_int32_t *pnumber, struct evbuffer *evbuf, int > dodrain) > 154: { > > Take a look through the list archives - Jan Kneschke posted a bunch of > patches on the 14th for compiling on Solaris, subject line "compile > patches for non-gcc". > > > > ________________________________ > Be a better Globetrotter. Get better travel answers from someone who knows. > Yahoo! Answers - Check it out. > > > _______________________________________________ > Libevent-users mailing list > Libevent-users@monkey.org > http://monkey.org/mailman/listinfo/libevent-users > >