[cgl_discussion] libevent & epoll

Frederic Rossi (LMC) Frederic.Rossi at ericsson.ca
Thu Aug 14 11:38:50 PDT 2003


Mika Kukkonen wrote:


>On Thu, 2003-08-14 at 05:59, Frederic Rossi (LMC) wrote:
>  
>
>>To compare what?? AEM can be combined with signals, epoll or select.
>>    
>>
>						      =====
>Could you explain how you combine AEM with epoll, as that is new to me?
>  
>

You can have a look at the testsuite which is the AEM web page. It was
published somewhere last April or May by Phillipe.
Also, we have a brand new module for TIPC. Since you are woking on TIPC,
we really would like to have your feedback on this too.

Plus, a new module for process exit notification (aem-pexit) and another 
one for
files and directories notification (aem-fd) for open, read, write, close,
chmod, chown, etc...
This is to show what can be done with AEM and how generic it is. I don't
plan to maintain all modules if nobody is interested.

The first one (aem-pexit) is a kind of a reply to a problem wich was 
mentioned
some time ago on the list (notifiy a process when another exists).
Also, examples were added to the package for each of the features so that
people can test them.

We would appreciate to have your feedbacks and tell us if you like the
interface (API), the functionalities and so on.

>Anyway I think the general "feeling" seems to be, that of those three
>methods you listed, epoll has most potential use in CGL.
>  
>
>>Each of these mechanisms provides different solutions for different
>>kind of problems. Find your problem then you will find your solution. 
>>
>>AEM is proposing one solution for Telecom applications running in the
>>context of a carrier-grade Linux as described in
>>http://aem.sourceforge.net/reports/AEM_cgl_reqts_draft0.6.pdf
>>    
>>
>
>I have said this earlier and will now say it again: until you get the
>other NEP's in CGL convinced of AEM's "exceptional qualities", AEM is 
>not going any further in CGL, meaning that I will be happy to keep it
>as a PoC reference, but that is it.
>
>And now that we seem to have an alternative (until proven otherwise)
>with libevent + epoll, WHICH IS ALREADY MAINLINED (i.e. epoll is in
>2.5/2.6 and I can download libevent RPM to my rh9), I strongly suggest
>that Specs-sg add that as a PoC reference to relevant requirements.
>  
>
The reality is that we are building a system to satisfy Telecom requirements
not to compete with other solutions. This should be a team work (between
us at OSDL) and not something I have to impose.

But you are right, any alternative must be proven efficient for Telecom 
purposes.
I think I will be interested to see TIPC working with libevent (or 
others) under
a real workload.

>  
>
>>Mika:
>>At Ottawa (or a few days before) we also said that if your are satisfied
>>with epoll+lib, then just use it.
>>    
>>
>
>Yes.
>

>--MiKu
>
>  
>

Frederic




More information about the cgl_discussion mailing list