[omniORB-dev] Efficient single thread use of omniORB...

[Michael Burbidge]

I'm trying to implement a fairly large Corba API in a legacy  
application. I say legacy, because the application is not thread  
safe. All processing must be done in the main thread. This  
application has a sophisticated idle task architecture for doing  
background processing. It was relatively easy for me to get omniOrb  
working using work_pending and perform_work. However it is proving to  
be fairly difficult to get it working efficiently.

In this application, idle tasks can indicate when they next want to  
get called. They can indicate this in terms of an elapsed time or  
they can just indicate that they would like to get called next time  
around the event loop. Rather than just spinning, the application can  
then block in the main event loop waiting either for a new event, or  
time to elapse till an idle task has requested to be called.

The challenge is that to efficiently handle corba requests, the idle  
task that handles them has to specify a small enough elapsed time  
that the application sucks up CPU cycles just waiting for corba  
requests.

What would really be nice, is if omniORB provided another function  
that would work in conjunction with work_pending. This function would  
block waiting for a corba request. When a request came in it would  
unblock and return, with the expectation that the request would then  
be processed by perform_work. The function would be called something  
like wait_for_work.

This would enable me to create a thread, whose job was simply to  
block waiting for a pending corba request. When a request came in it  
would send an event to the main event loop which would immediately  
unblock and process any idle tasks that needed processing. It might  
look something like:

void Thread()
{
     while (true)
     {
         orb->wait_for_work();
         wakeup_main_event_loop();
     }
}

I'm guessing that others that have tried to efficiently use the  
work_pending and perform_work methods have faced similar challenges.

I would be willing to implement this function if someone can point me  
in the right direction. I'm assuming it would be relatively simple to  
implement.

Thanks,
Michael-