Thanks Tom, I know there is a simple summary about threading ( http://www.wangafu.net/~nickm/libevent-book/Ref1_libsetup.html), but it is too general. The goal I am sending this post is that I want to know is there any code examples I can reference. I suppose such idea is very common to implement a real-world system, so I don't want to reinvent the wheel.
Thanks Michael [email protected] From: Tomer Heber Date: 2016-03-15 16:31 To: [email protected]; [email protected] Subject: RE: RE: [Libevent-users] std::threads Hi, “So, I want to put all of the socket_bufferevents in one event_base, and only one thread is runing the event_base. When one of the socket_bufferevents can read or write, the associated callback will pass the read/write data to a thread to process. I suppose this model is more reasonable, right?” Correct. Please check http://www.wangafu.net/~nickm/libevent-book/Ref1_libsetup.html specifically that section about “Locks and threading”. You will have to implement some functions. Once you have implemented these functions you are good to go. 10x, Tomer. From: [email protected] [mailto:[email protected]] On Behalf Of Michael (Tieying) Zhang Sent: Tuesday, March 15, 2016 11:22 AM To: libevent-users <[email protected]>; [email protected] Subject: Re: RE: [Libevent-users] std::threads Thanks Tom. "event bases + threads (each thread running an event base)", that is what I have done. Each connection is a thread with a event_base + a socket_bufferevent. But when a connection has no communication during sometime, the associated thread is idle. That's the main problem I concern. For example, there are 10 connections with the server, and 10 threads on the server are responsible for the connections, e.g., thread-1 is associated with connection-1, with event_base-1 and socket_bufferevent-1. If the client with the connection-1 stop sending messages to the server, the thread-1 is stuck. Becuase thread-1 is running dispatch(event_base-1), which is a blocking API. So, I want to put all of the socket_bufferevents in one event_base, and only one thread is runing the event_base. When one of the socket_bufferevents can read or write, the associated callback will pass the read/write data to a thread to process. I suppose this model is more reasonable, right? The question is how can I implement that with std::thread. Because our project use std::thread. I see libevent can use pthread (even though there is no example in the documentation) but I am don't know how to use it with std::thread. The explaination is so simple I do not know how to implement it with std::thread. Michael [email protected] From: Tomer Heber Date: 2016-03-15 12:22 To: [email protected]; [email protected] Subject: RE: [Libevent-users] std::threads Hi Michael, Using a thread for each connection is exactly what libevent (async IO) is trying to simplify and prevent. The right way would be to use a single event base with a single thread for all these connections. If you want to scale it to multiple cores: you can divide the connections between a couple of event bases + threads (each thread running an event base). 10x, Tomer. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Michael Sent: Tuesday, March 15, 2016 8:58 AM To: [email protected] Subject: [Libevent-users] std::threads Hi All, This is Michael from CMU. I am currently using libevent in our database system (https://github.com/cmu-db/peloton/wiki) to let the cluster nodes to communicate with each other. I want to ask how can I use multiple std::threads on the same event_base. For example, a server has a event_base. When a new connection coming, the server creates a std::thread with a socket_event, and puts the socket_event into the event_base. If there are ten connections, there are ten std::threads sharing the same event_base. (Each threads has it own socket_event to recv and send data). Can I implement that? Is there an example? I appreciate your help! Best, Michael *********************************************************************** To unsubscribe, send an e-mail to [email protected] with unsubscribe libevent-users in the body.
