Re: linc-0.1.13, ORBit2-2.3.102

[Michael Meeks <michael ximian com>]

Hi Sebastian,

	Great - the problems you were facing, are now substantially fixable :-)

On Thu, 2002-01-10 at 11:56, Sebastian Wilhelmi wrote:
> If you have a pull_supplier (or a push_consumer), then the server has to
> call the client. The client however might not be able to take events
> just now (have any event ready resp.) and thus block. That would make
> the server block too. Bad. That can be solved via DII. 

	Ok - we can also do this with the async code which should be relatively
easy I think.

> Next problem. If you have a pull_consumer, then the server is called by
> the client, whenever it want to fetch a new event. The server might not
> have that event ready, so the whole thing recurses. But how to later
> break out of that recursion, if an event for a request came in, but you
> can't unwind the stack, as another request in between is still
> unanswered.

	Yes - this is harder; currently we could do this inside the ORB by
overriding the 'handle incoming call' virtual method on those objects
and doing asynchronous queueing of such things. However, I'm not sure
that that's neccessary, you can always poke at the stack lower down by
keeping a set of pointers to requests on the stack - or perhaps I don't
understand this one.

> My first thought was multithreading. That's the whole reason I got
> involeved with ORBit-mt and threads in GLib and so on. But being in
> multithread hell (debugging is a nightmare, locking costs not so low
> either, portability less than satifying) I think, doing it
> singlethreaded would be possible and I even have some good ideas, but
> alas no time whatsoever just now. But in a few months I will hopefully
> have finished my Ph.D. thesis. Then I think, I'll have some time and
> might start with that. I guess, that with a good design the event server
> can be quite small (in LoC).

	That'd be great :-) especially if you designed a nice API for async
server impl.s something I'm personally very interested in in my quest to
rid the world of nautilus' adaptor component.

	Regards,

		Michael.

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