Re: Orbit Performance Questions

[Michael Meeks <michael ximian com>]

Hi Wen,

On Mon, 2001-12-31 at 16:27, dou wen wrote:
> hi Meeks,

	Apoligies; how do you like to be addressed ? I usualy asusme first
names - is yours 'dou' or 'wen' [ ERDI Gergo has confused me here =]

> as you point out,the glib in kernel surely is too big for me, i have already cut off some of them,
> such as codeset part etc.  and intend to cut off more of them. :-) 

	Sure - lots of it can go I think; we need ghash, glist, gslist, some of
gthread, some string bits, gobject/* and not much more I think. [
although you prolly don't need the gsignal stuff really we can do
without signals AFAIR - they are slow & not thread safe so we keep them
off the critical paths ].

>   glad to hear that, i have not carefully read the orbit2 's
> implemention code, just debug and hack the echoserver sample,

	Fair enough.

> and i feel the orbit2 use many gthread's lock mechanisms,which is
> actually depend on posix thread 's locks(in my x86/linux box) ,you
> mean i just need port the lock constructing mechanisms using kernel's
> replacement?

	Yes - pretty much; 'linc/ORBit2' is (currently) purely a single thread
of ORB [ though in theory invocations could come in from many threads ].

>   hmm,Meeks,then how orbit2 implement the "per thread /per request"
> policy? it seem orbit2 indeed first queue the requests then handle
> them serialized? 

	We don't implement that policy currently - instead we try to do
non-blocking IO wherever possible, and have a re-enterant incoming
request processing strategy when we have to 'block'. So ... of course,
we'd very much like to implement the thread / per request policies etc.
but this will take some considerable work and testing.

	Regards,

		Michael.

-- 
 mmeeks@gnu.org  <><, Pseudo Engineer, itinerant idiot