ORBit2 asyncness ...

[Michael Meeks <michael ximian com>]

Hi Mark,

On Thu, 2002-09-05 at 04:56, Mark McLoughlin wrote:
> 	Anyway, it is food for thought - there's no point
> in ignoring the thought already gone into solving this
> problem ...

	One of the (serious) performance problems in nautilus, comes from the
'adaptor'.

	The 'adaptor' was designed to get around the synchronous nature of
incoming and outgoing CORBA calls; previously eg. nautilus needs to
recieve 'read' requests on it's Stream object, but may not have the data
to fulfill them, thus it blocks in the CORBA impl, and the GUI doesn't
respond. The Eazel soln' was (instead of tackling the problem at root)
to fork another component that it pokes 'oneways' at [ until it's buffer
fills ] that 'adapts' the object and does the blocking CORBA work.

	This still screws us when using really high latency sources and wanting
to browse eg. images quickly. So ...

	What we _really_ need is a GEP on asynchronous implementations - and to
look up the specs for how to implement the 2.6 Async extensions sensibly
in C - in the IDL compiler, and elsewhere [ if they make sense in fact
].

	Then we can bin the adaptor, and make nautilus browsing nicer and
faster - and provide a powerful tool to the rest of the platform. I'd
far prefer to provide this than put work into making ORBit 'thread
safe', which is going to be far harder, and make life even more complex
for the programmer [ Sebastian agrees with this too ironicaly ].

	What do you say ?

	Regards,

		Michael.

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