Re: [Libevent-users] Process terminating with default action of signal 13 (SIGPIPE)
Hi! On Fri, Jun 26, 2009 at 03:01:19PM +0600, Rauan Maemirov wrote: Hi, Clint. Thanks for the answer. But I was interested how can i solve it in the scope of libevent. You can't. Handling signals is a global effect, so libraries shouldn't touch them implicitly, instead the main program should. It's the way it is with Unix/POSIX signals. SIGPIPE is just a very nasty case because of its default settings. [...] Kind regards, Hannah. ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] bufferevent -- detect connect() error
Hi! On Wed, Jan 21, 2009 at 06:16:47PM -0500, arthur wrote: When I connect to a remote unreachable tcp port, connect() return -1 (with errno as EINPROGRESS). If I use event_add, I can get read event later and then getsockopt(fd, SOL_SOCKET, SO_ERROR,..) will tell me error. Just a note: For tracking a non-blocking connect, you use a *write* event, not a *read* event. Using the getsockopt you specify is right then. For successful connects, the read event would not trigger once the connection is established, but only after something is *received* (e.g. a server greeting) or when the connection is closed again (e.g. server timeout). In contrast, the write event will trigger both on successful connect, as well as on connection failure. If I create bufferevent_new with the connect fd directly, I got no event any all. Can I get connect() error with bufferevent? Can't answer that, alas. Haven't used bufferevents yet. Could you use vanilla events to track wait for the connection to be established (unless you get a zero return from connect() already) and only *then* start using bufferevents? Kind regards, Hannah. ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] bufferevent -- detect connect() error
Hi! On Thu, Jan 22, 2009 at 10:01:35AM -0500, arthur wrote: Just a note: For tracking a non-blocking connect, you use a *write* event, not a *read* event. ... Thanks Hannah and Niels. That is the point, I didn't register write cb for the connecting fd (with my old event_add code, the notification came from read :)) A notification *can* come for read: On error or server greeting or the server closing the connection again (e.g. a server timeout when the server is tired of waiting for the client sending something). You might just wait longer than you really want to. Here another q regarding bufferevent (with listening tcp fd). Now I got connection event from error cb (with error what==0x21) Please decode the numerical values again (if it's errno values, they're specific to the platform you're using! but even if it's libevent values, it's just not as readable as the symbolic constants or several of them or'ed together). to accept a new client. Is this the expected behavior? Do I need read/write cb for listening fd? You use a read event (and as you noticed yourself in the subsequent mail, you can use vanilla events). A listener fd becomes readable if you can call accept() at least once without blocking (or yielding only EAGAIN if it's non-blocking). On Thu, Jan 22, 2009 at 10:27:27AM -0500, arthur wrote: Here another q regarding bufferevent (with listening tcp fd). Now I got connection event from error cb (with error what==0x21) to accept a new client. Is this the expected behavior? Do I need read/write cb for listening fd? Comment my own q: maybe I shouldn't use bufferevent for listen fd (which won't send/receive). I see http.c uses event_add. Thanks anyway. Arthur Right. A listener socket is good about only for accept (or close, later), except for perhaps a few esoteric things (which I'm less aware of, dunno whether you can query things on the next connection to be accept()ed before accepting it on some platforms, for example, or query the number of pending connections). Kind regards, Hannah. ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] Proposal: Change libevent-users list reply to use the list as default
Hi! On Thu, Jan 01, 2009 at 06:21:48PM -0800, Michael Carter wrote: The libevent-users list is configured such that when you hit reply it sends the response directly to the user who posted, not the list itself. You can use reply all, of course, but its cumbersome. Reasonable mail readers have reply (in private), reply all (group reply) *and* reply to list functions. If you set a reply-to header, you cut down the choice of the users of those mail readers arbitrarily. [...] It hurts the community to not have all discussion publicly logged. Sometimes people have similar questions, and their question has been previously asked, but they can't see any response to that question. It happens to me at any rate, and I don't know if the original question was ignored or just responded to directly. Perhaps that's by choice sometimes. Kind regards, Hannah. ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] files and libevent
Hi! On Sat, Jun 14, 2008 at 02:03:20PM -0400, Nick Mathewson wrote: On Thu, Jun 12, 2008 at 07:59:45AM -0700, Teunis Peters wrote: I've not found any code to work with - but is there any reason that libevent would not work with standard files? I keep getting permission denied more or less: fd = open(filename, O_RDONLY) event_set(ev, EV_READ | EV_PERSIST, rd_callback, rd_data); event_add(ev, NULL) - EPERM Or does libevent only work with network connections? Libevent uses underlying nonblocking IO mechanisms the platform gives it. Some of these work well with non-socket file descriptors; some don't. By default, libevent uses the fastest (best-scaling) backend that it knows about for your platform, even if that backend doesn't support all fds. In the current svn trunk (which will eventually become libevent 2.0), there's a feature to let you specify that you want a backend that works with file descriptors, even if it doesn't scale well. On most OSes, however, checking for readable on plain files always immediately returns/yields a readable event anyway, so it's of no use (e.g. select/poll on Unix, I guess the same for epoll/kqueue, ok, kqueue differs from select/poll in that it returns readable if you're not at EOF, unless you set an additional flag, and then it returns in all cases). You have to use different mechanisms (like aio) if you want to hide disk latencies on plain files without using separate threads for their manipulation. So I think, using libevent events on plain files usually just doesn't make much sense in my eyes. Kind regards, Hannah. ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] [OT] craigslist: libevent programmer wanted
Hi! On Thu, Nov 08, 2007 at 02:19:25PM -0800, Christopher Layne wrote: On Thu, Nov 08, 2007 at 08:11:55AM -0800, Garth Patil wrote: http://sfbay.craigslist.org/pen/cpg/472325599.html libevent programmer wanted (san mateo) - NOT BLOCK ON ANY STEP close() can block. *boom tsst*. On sockets, IIRC only with non-standard settings of the SO_LINGER option. The setsockopt(4) manual page, on OpenBSD, says: SO_LINGER controls the action taken when unsent messages are queued on socket and a close(2) is performed. If the socket promises reliable de- livery of data and SO_LINGER is set, the system will block the process on the close(2) attempt until it is able to transmit the data or until it decides it is unable to deliver the information (a timeout period mea- sured in seconds, termed the linger interval, is specified in the setsockopt() call when SO_LINGER is requested). If SO_LINGER is disabled and a close(2) is issued, the system will process the close in a manner that allows the process to continue as quickly as possible. And IIRC, SO_LINGER *is* disabled by default. So if you want close not to block, you either keep SO_LINGER disabled or set the linger timeout to zero (which specifies *different* behaviors!). And then, for HTTP, this should be relatively irrelevant, as usually the client (and the task specified was a HTTP *client*, not a server) closes the connection only after receiving the response, and the server even only *starts* sending the response after having received the whole request, so the transmit buffer of the socket should be empty anyway when the client closes the socket. Kind regards, Hannah. ___ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
Re: [Libevent-users] [PATCH] Fix syntax error in autogen.sh
Hi! On Thu, Sep 20, 2007 at 03:23:32PM +0200, Trond Norbye wrote: Magne Mæhre wrote: Changing to /bin/bash isn't a good solution, since you're not guaranteed to have bash on every system (nor that it's in /bin) I would suggest to have the script Bourne shell compliant instead : SYSNAME=`uname` if [ $SYSNAME = Darwin ] ; then LIBTOOLIZE=glibtoolize fi You're right, thats a much better solution (I just assumed it would be bash since I've heard that most Linux distributions provides /bin/sh as a link to bash). Not all the world is Linux. I'd suggest if [ X$SYSNAME = XDarwin ] ... to be really safe, btw. Trond Kind regards, Hannah. ___ Libevent-users mailing list Libevent-users@monkey.org http://monkey.org/mailman/listinfo/libevent-users
