[cgl_discussion] Re: [cgl_specs] Support for asynchronous events

Frederic Rossi (LMC) Frederic.Rossi at ericsson.ca
Tue Nov 12 06:38:02 PST 2002


Hi,

Thanks for your interest.
No it's completly different from signals. The purpose is to have a user 
space API
providing an event-driven mechanism. The way it works is the following: 
events are
dropped into wait queues and awaken when activated. Object used for this 
are called "jobs"
which to some extent are equivalent to threads. When a user register an 
event, a job is created
and pushed into the corresponding waitqueue or scheduled periodically 
depending on events.
Signals are not used, callback functions are directly called from kernel 
space with all
data in parameter. Callbacks or event handlers are specific to event 
types but
define their own list of parameter.

I'm also sending an article that was recently written for the Linux 
Journal. It is more
up to date than the slides on the web page. Probably it could help to 
clarify.

Frederic


Pradeep Kathail wrote:

>Hi Frederic,
>
>My understanding, from reading the requirements, is that you are looking 
>for asynchronous event delivery with priority queuing of events. At 
>surface this looks like a glorified method of delivering POSIX real-time signals. Is that what you want or am I missing something? If this 
>is what you want then, read-on?
>
>In a multi-threaded system, I have found programming with asynchronous 
>events to be cumbersome and error prone. I think programming model becomes
>simpler and more flexible, if you allow these events to be dropped into
>a queue that can be watched/ queried by various threads. One or more 
>threads should be able to sleep on this queue and woken up when events 
>are delivered/ available in the queue. At the same time polling of queue
>in the user space should be very efficient.
>
>Multi-threaded processes can have one or more threads waiting on this 
>queue and processing the event as they arrive. Application will also 
>have choice of tuning the number of threads based on arrival rate of
>events. Applications will be able to use normal locking primitives to
>protect critical sections and data structures.
>
>Single threaded applications should be able to poll the event on natural
>protection boundaries or create a small stub thread, that drops appropriate
>signal for processing thread to process the event.
>
>Pradeep
>At 11/8/2002 05:37 PM -0500, Frederic Rossi (LMC) wrote:
>
>>Hi everyone,
>>
>>During the OSDL F2F meeting in San Jose, support for asynchronous events 
>>in the Linux kernel was brought in FS1 - HA platform as part of the 
>>'new and wonderful features'.
>>
>>As a follow up, I am attaching a document that lists the requirements 
>>for the support of asynchronous events. It is a first draft and I would 
>>appreciate your feedback on it.
>>
>>The implementation is available for download at 
>>http://www.linux.ericsson.ca/async/
>>
>>Peter: In case a conference call is needed to discuss this further, 
>>please arrange for it. I am ready to run a slide show and go through
>>AE in details.
>>
>>Best regards,
>>Frederic
>>
>>
>><<AEM_reqts_PA6.doc>> 
>>
>>
>>
>>Ericsson Research Canada          frederic.rossi at ericsson.ca
>>Systems Research LMC/UU           Phone:  (514) 345-7900  x5641
>>8400 Decarie Blvd.
>>Town of Mount Royal
>>H4P 2N2, (Quebec) Canada
>>
>>
>>

-- 

Ericsson Research Canada          frederic.rossi at ericsson.ca
Systems Research LMC/UU           Phone:  (514) 345-7900  x5641
8400 Decarie Blvd.
Town of Mount Royal
H4P 2N2, (Quebec) Canada





-------------- next part --------------
A non-text attachment was scrubbed...
Name: aem_article.pdf
Type: application/pdf
Size: 211451 bytes
Desc: not available
Url : http://lists.linux-foundation.org/pipermail/cgl_discussion/attachments/20021112/5f978256/aem_article-0001.pdf


More information about the cgl_discussion mailing list