[omniORB] Thread and connection policy for very large configurations
baileyk@schneider.com
baileyk@schneider.com
Wed Apr 2 18:23:01 2003
My thought was that such a patch for using poll() would make it into
omniORB itself. If it is as you say, just as efficient and has less
restrictions to use poll() rather than select() I don't know why Duncan
wouldn't accept such a patch, especially if it allows the choice to be made
either at build time, or if feasible at run time. Maybe I don't know
enough of the ramification of switching from select() to poll() to give
good advice. I've read the relevant code in omniORB a while back, and my
first impression is that such a patch would not be terribly hard or
invasive.
Sounds like v4.0.1 is what you want, since Duncan mentioned that version
does not need my patch to eliminate the latency.
Kendall
Serguei Kolos
<Serguei.Kolos@cern.ch> To:
Sent by: cc: omniorb-list@omniorb-support.com
omniorb-list-admin@omniorb- Fax to:
support.com Subject: Re: [omniORB] Thread and connection policy for very large
configurations
04/02/2003 09:47 AM
Hi
Thank you for the replay.
>
For me the option 3 with the patch you mentioned looks very promising.
>Perhaps you could develop a
>patch for using poll(), and make it either a build-time or run-time
>configuration option.
>
This is probably a good idea. But what happens when the new version of the
omniORB appears? I guess I'll need to rewrite my patch.
Could it be done in a different way - could the OMNI itself provides an
API for
Cheers,
Sergei