headers
liusifan | 2 Sep 2008 08:54
Picon

Support UDP socket and pass evdns test case by libevent IOCP backend

Hi, all

http://spserver.googlecode.com/files/libevent-1.4.7-stable-iocp-1.zip

Integrate iocp backend with libevent-1.4.7-stable.

Change since libevent-1.4.5-stable-iocp-2.zip
* Support UDP socket, pass evdns regress test case
* Add evdns_test
* Add http_test

The IOCP backend use getsockopt to distinguish TCP/UDP socket.
Before calling event_del, the socket must not been closed.
It requires to make some change in evdns.c .
The detail diff please refer 
libevent-1.4.7-stable-iocp-1\WIN32-Code\diff-1.4.7

This package is still not perfect. 
* Need a new flag -- EV_CONNECT to distinguish connect/write event
* The http regress test case still cannot pass

Best Regards,

Stephen Liu
Permalink | Reply | 0 comments |
headers
awantik.das | 4 Sep 2008 06:53

How do I modify polling time in lib-event ???

Hi All,

            For different application, I need different polling time. How do I configure polling time of lib-event ???

Thanks in advance.

 

Thanks & Regards

Awantik Das

+91 9987796932

_______________________________________________
Libevent-users mailing list
Libevent-users <at> monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
Permalink | Reply | 0 comments |
headers
Jonathan Hohle | 4 Sep 2008 17:24
Favicon

Re: Clarification on threading

I have recently added some code to do the following: - Setup a worker pool of threads that sit waiting on a condition variable. - The main thread takes the request struct and puts it in to the queue of a thread, wakes the thread up and asks the thread to deal with it. - Main thread returns to even processing. - Thread answers the request and then goes back to sleep. The problem I have is that it'll process one request and then stop.

...but I wondered if anyone had any words of wisdom.
I don't know if this helps or not, but I recently set up a app with a similar architecture. Originally it used a single event base which handled accepts and reads. I thought: why don't I just separate those into separate threads (in my case a single accept thread, and multiple read threads, with round-robin event queuing).

Things went well *until* I had more concurrent connections than I had reader threads. I banged my head over my locking strategy for several days, but finally came to the conclusion that event_add/event_base_loop are not thread safe (at least in libevent 1.4.x).

In the typical case, you're adding events either in an event handler callback, or before the event loop has begun. In a case with multiple threads and multiple event loops, there is no clear indication of when an event is added to the queue. (Someone please correct me if I'm wrong).

I can't find the tab atm, but I have seen some discussion about multi-threading support being present in trunk. I haven't gotten trunk to build yet, however. For now I think I'm going to revert to a single queue, giving priority to read events.

On the other hand, having a per-connection thread with its own event queue works perfectly fine (in my experience). Under heavy load, however, you can spawn a lot of threads ;)

Jonathan Hohle
pstn: 480.505.8800_.4324
voip: 4324
cdma: 480.323.5799
<><



_______________________________________________
Libevent-users mailing list
Libevent-users <at> monkey.org
http://monkeymail.org/mailman/listinfo/libevent-users
Permalink | Reply | 501 comments |
headers
Tani Hosokawa | 4 Sep 2008 18:20

Re: Re: Clarification on threading

FWIW, I have written a similar system which uses a dedicated accept 
thread and a pool of read/write threads (1 per CPU) and it works fine 
with over 20000 concurrent connections.  Using a thread per connection 
is the exact opposite of what event based processing is intended for.

Jonathan Hohle wrote:
>> I have recently added some code to do the following: - Setup a worker 
>> pool of threads that sit waiting on a condition variable. - The main 
>> thread takes the request struct and puts it in to the queue of a 
>> thread, wakes the thread up and asks the thread to deal with it. - 
>> Main thread returns to even processing. - Thread answers the request 
>> and then goes back to sleep. The problem I have is that it'll process 
>> one request and then stop.
>
>> ...but I wondered if anyone had any words of wisdom.
> I don't know if this helps or not, but I recently set up a app with a 
> similar architecture. Originally it used a single event base which 
> handled accepts and reads. I thought: why don't I just separate those 
> into separate threads (in my case a single accept thread, and multiple 
> read threads, with round-robin event queuing).
>
> Things went well *until* I had more concurrent connections than I had 
> reader threads. I banged my head over my locking strategy for several 
> days, but finally came to the conclusion that 
> event_add/event_base_loop are not thread safe (at least in libevent 
> 1.4.x).
>
> In the typical case, you're adding events either in an event handler 
> callback, or before the event loop has begun. In a case with multiple 
> threads and multiple event loops, there is no clear indication of when 
> an event is added to the queue. (Someone please correct me if I'm wrong).
>
> I can't find the tab atm, but I have seen some discussion about 
> multi-threading support being present in trunk. I haven't gotten trunk 
> to build yet, however. For now I think I'm going to revert to a single 
> queue, giving priority to read events.
>
> On the other hand, having a per-connection thread with its own event 
> queue works perfectly fine (in my experience). Under heavy load, 
> however, you can spawn a lot of threads ;)
>
> Jonathan Hohle
> smtp: jhohle <at> godaddy.com <mailto:jhohle <at> godaddy.com>
> pstn: 480.505.8800_.4324
> voip: 4324
> cdma: 480.323.5799
> <><
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Libevent-users mailing list
> Libevent-users <at> monkey.org
> http://monkeymail.org/mailman/listinfo/libevent-users
>
Permalink | Reply | 502 comments |
headers
Chris Ross | 4 Sep 2008 18:40
Picon
Gravatar

Re: Re: Clarification on threading


Thanks for the information.

Since the first post, I have implemented a dedicated listening/reading  
thread with libevent with a pool of worker threads. The incoming  
requests are read, packaged and handed over to a thread (knows nothing  
of libevent) which will then perform the request and then write the  
data back and go back to sleep. Seems to work nicely. It did require  
me to write my own http server but hey - such is life.

Chris

On 4 Sep 2008, at 17:20, Tani Hosokawa wrote:

> FWIW, I have written a similar system which uses a dedicated accept  
> thread and a pool of read/write threads (1 per CPU) and it works  
> fine with over 20000 concurrent connections.  Using a thread per  
> connection is the exact opposite of what event based processing is  
> intended for.
>
> Jonathan Hohle wrote:
>>> I have recently added some code to do the following: - Setup a  
>>> worker pool of threads that sit waiting on a condition variable. -  
>>> The main thread takes the request struct and puts it in to the  
>>> queue of a thread, wakes the thread up and asks the thread to deal  
>>> with it. - Main thread returns to even processing. - Thread  
>>> answers the request and then goes back to sleep. The problem I  
>>> have is that it'll process one request and then stop.
>>
>>> ...but I wondered if anyone had any words of wisdom.
>> I don't know if this helps or not, but I recently set up a app with  
>> a similar architecture. Originally it used a single event base  
>> which handled accepts and reads. I thought: why don't I just  
>> separate those into separate threads (in my case a single accept  
>> thread, and multiple read threads, with round-robin event queuing).
>>
>> Things went well *until* I had more concurrent connections than I  
>> had reader threads. I banged my head over my locking strategy for  
>> several days, but finally came to the conclusion that event_add/ 
>> event_base_loop are not thread safe (at least in libevent 1.4.x).
>>
>> In the typical case, you're adding events either in an event  
>> handler callback, or before the event loop has begun. In a case  
>> with multiple threads and multiple event loops, there is no clear  
>> indication of when an event is added to the queue. (Someone please  
>> correct me if I'm wrong).
>>
>> I can't find the tab atm, but I have seen some discussion about  
>> multi-threading support being present in trunk. I haven't gotten  
>> trunk to build yet, however. For now I think I'm going to revert to  
>> a single queue, giving priority to read events.
>>
>> On the other hand, having a per-connection thread with its own  
>> event queue works perfectly fine (in my experience). Under heavy  
>> load, however, you can spawn a lot of threads ;)
>>
>> Jonathan Hohle
>> smtp: jhohle <at> godaddy.com <mailto:jhohle <at> godaddy.com>
>> pstn: 480.505.8800_.4324
>> voip: 4324
>> cdma: 480.323.5799
>> <><
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Libevent-users mailing list
>> Libevent-users <at> monkey.org
>> http://monkeymail.org/mailman/listinfo/libevent-users
>>
>
> _______________________________________________
> Libevent-users mailing list
> Libevent-users <at> monkey.org
> http://monkeymail.org/mailman/listinfo/libevent-users
Permalink | Reply | 1 comment |
headers
Tani Hosokawa | 4 Sep 2008 18:50

Re: Re: Clarification on threading

Actually, I'm using evhttp for processing the requests.  Pretty much 
stock libevent if you're using the latest version, and only minor 
thread-safety issues in the really old versions and then only for 
outbound HTTP connections.

Chris Ross wrote:
>
> Thanks for the information.
>
> Since the first post, I have implemented a dedicated listening/reading 
> thread with libevent with a pool of worker threads. The incoming 
> requests are read, packaged and handed over to a thread (knows nothing 
> of libevent) which will then perform the request and then write the 
> data back and go back to sleep. Seems to work nicely. It did require 
> me to write my own http server but hey - such is life.
>
> Chris
>
> On 4 Sep 2008, at 17:20, Tani Hosokawa wrote:
>
>> FWIW, I have written a similar system which uses a dedicated accept 
>> thread and a pool of read/write threads (1 per CPU) and it works fine 
>> with over 20000 concurrent connections.  Using a thread per 
>> connection is the exact opposite of what event based processing is 
>> intended for.
>>
>> Jonathan Hohle wrote:
>>>> I have recently added some code to do the following: - Setup a 
>>>> worker pool of threads that sit waiting on a condition variable. - 
>>>> The main thread takes the request struct and puts it in to the 
>>>> queue of a thread, wakes the thread up and asks the thread to deal 
>>>> with it. - Main thread returns to even processing. - Thread answers 
>>>> the request and then goes back to sleep. The problem I have is that 
>>>> it'll process one request and then stop.
>>>
>>>> ...but I wondered if anyone had any words of wisdom.
>>> I don't know if this helps or not, but I recently set up a app with 
>>> a similar architecture. Originally it used a single event base which 
>>> handled accepts and reads. I thought: why don't I just separate 
>>> those into separate threads (in my case a single accept thread, and 
>>> multiple read threads, with round-robin event queuing).
>>>
>>> Things went well *until* I had more concurrent connections than I 
>>> had reader threads. I banged my head over my locking strategy for 
>>> several days, but finally came to the conclusion that 
>>> event_add/event_base_loop are not thread safe (at least in libevent 
>>> 1.4.x).
>>>
>>> In the typical case, you're adding events either in an event handler 
>>> callback, or before the event loop has begun. In a case with 
>>> multiple threads and multiple event loops, there is no clear 
>>> indication of when an event is added to the queue. (Someone please 
>>> correct me if I'm wrong).
>>>
>>> I can't find the tab atm, but I have seen some discussion about 
>>> multi-threading support being present in trunk. I haven't gotten 
>>> trunk to build yet, however. For now I think I'm going to revert to 
>>> a single queue, giving priority to read events.
>>>
>>> On the other hand, having a per-connection thread with its own event 
>>> queue works perfectly fine (in my experience). Under heavy load, 
>>> however, you can spawn a lot of threads ;)
>>>
>>> Jonathan Hohle
>>> smtp: jhohle <at> godaddy.com <mailto:jhohle <at> godaddy.com>
>>> pstn: 480.505.8800_.4324
>>> voip: 4324
>>> cdma: 480.323.5799
>>> <><
>>>
>>>
>>>
>>> ------------------------------------------------------------------------ 
>>>
>>>
>>> _______________________________________________
>>> Libevent-users mailing list
>>> Libevent-users <at> monkey.org
>>> http://monkeymail.org/mailman/listinfo/libevent-users
>>>
>>
>> _______________________________________________
>> Libevent-users mailing list
>> Libevent-users <at> monkey.org
>> http://monkeymail.org/mailman/listinfo/libevent-users
>
Permalink | Reply | 0 comments |
headers
Thomas Harning Jr. | 6 Sep 2008 07:12
Picon
Gravatar

Wrapping C++ hidden in C, good for uptake, or is any C++ frowned upon (for my Lumina networking library)

I'm looking at developing a networking framework somewhat styled after
what Mina offers in Java.. but native and optionally scriptable
through wrappers.

I've been looking at doing it in C, but there seems to be so much
extra overhead while implementing data hiding, custom memory
management, and some basic inheritance.

I've recently done some work in C++ and got the taste of the
compacting of certain management tasks into small type-safe pieces of
code.....

I'm hoping that when my library is in good shape that other
open-source developers can consume it, however I've often seen that
C++ is viewed as "evil" and avoided in any projects.  Since I plan on
using libev and/or libevent pieces, I figured that the project may be
of the most use to subscribers of this list.... I figured I'd poll you
all....

Basically the plan is to develop objects in this fashion:

* C Interface w/ either publicly exposed structs, or typedefs for
structs not-yet-defines. + usage functions
* C++ Implementation Interface inheriting/implementing from structs in
C interface
* C function implementation calling the C++ implementation interface functions
* C++ Implementation - actual guts

Example:

IoAccepter.h:
struct IoAccepter {
  IoManager *manager;
  IoHandler *handler;
};

IoAccepter *IoAccepter_new(IoManager *manager, IoHandler *handler);
int IoAccepter_bind(IoAccepter *accepter, const struct sockaddr *addr,
socklen_t addr_len);

IoAccepter.hpp:
class IoAccepter_impl : public IoAccepter {
public:
IoAccepter(IoManager *manager, IoHandler *handler);
int bind(const struct sockaddr *addr, socklen_t addr_len);
private:
/* already-bound sockets -> addresses ... */
}
/* binding layer */
extern "C" {
IoAccepter *IoAccepter_new(IoManager *manager, IoHandler *handler) {
  return new IoAccepter_impl(manager, handler);
}
int IoAccepter_bind(IoAccepter *accepter, const struct sockaddr *addr,
socklen_t addr_len) {
  return ((IoAccepter_impl*)accepter)->bind(addr, addr_len);
}

IoAccepter.cpp ..... deeper impl

Any views on this... perhaps there's a better solution I hadn't
thought of.  (I've seen glib and its large set of utilities for
object-orientation in C... but it seems just too large and clunky....)
--

-- 
Thomas Harning Jr.
Permalink | Reply | 3 comments |
headers
Adrian Chadd | 6 Sep 2008 07:16
Picon
Gravatar

Re: Wrapping C++ hidden in C, good for uptake, or is any C++ frowned upon (for my Lumina networking library)

On Sat, Sep 06, 2008, Thomas Harning Jr. wrote:
> I'm looking at developing a networking framework somewhat styled after
> what Mina offers in Java.. but native and optionally scriptable
> through wrappers.

[snip]

> I've recently done some work in C++ and got the taste of the
> compacting of certain management tasks into small type-safe pieces of
> code.....

boost::asio seems relatively sane; perhaps you want to check out their
API and internals?

Adrian
Permalink | Reply | 2 comments |
headers
Thomas Harning | 7 Sep 2008 03:29
Picon
Gravatar

Re: Wrapping C++ hidden in C, good for uptake, or is any C++ frowned upon (for my Lumina networking library)

After thinking through some potential issues, particularly permitting  
others to integrate and extend libraries, I found the major killer for  
C++ libraries.. (especially on Windows where there's competing VC++  
versions as well as MinGW).... ABI incompatibility.

I 'might' think of integrating boost's asio, but that would be hidden  
from the C API (perhaps selectable through some configuration setup)...

I hope that C++-(whatever's next) will usher in ABI compatibility...  
but that may be wishing too much.

Just wondering, is there any useful languages on top of C that would  
help code this, perhaps some preprocessing tools that would help take  
care of some gruntwork... or perhaps some sort of light C library that  
helps w/ object-orientation...

On Sep 6, 2008, at 1:16 AM, Adrian Chadd wrote:

> On Sat, Sep 06, 2008, Thomas Harning Jr. wrote:
>> I'm looking at developing a networking framework somewhat styled  
>> after
>> what Mina offers in Java.. but native and optionally scriptable
>> through wrappers.
>
> [snip]
>
>> I've recently done some work in C++ and got the taste of the
>> compacting of certain management tasks into small type-safe pieces of
>> code.....
>
> boost::asio seems relatively sane; perhaps you want to check out their
> API and internals?
>
>
>
>
> Adrian
>
Permalink | Reply | 1 comment |
headers
Adrian Chadd | 7 Sep 2008 03:33
Picon
Gravatar

Re: Wrapping C++ hidden in C, good for uptake, or is any C++ frowned upon (for my Lumina networking library)

On Sat, Sep 06, 2008, Thomas Harning wrote:

> Just wondering, is there any useful languages on top of C that would  
> help code this, perhaps some preprocessing tools that would help take  
> care of some gruntwork... or perhaps some sort of light C library that  
> helps w/ object-orientation...

I saw something written in java that took descriptions of processing
modules and the graph linking them together.

I thought it was an interesting idea. I just can't remeber what its called
now!

Adrian
Permalink | Reply | 0 comments |

Gmane