Re: linc-0.1.13, ORBit2-2.3.102

[Sebastian Wilhelmi <wilhelmi ira uka de>]

Hi Michael,

> > Unless someone really implemented the event server for ORBit, which I
> > don't think, there is no use in porting the event server from ORBit to
> > ORBit2, because it just isn't even near an event server. It's just
> > rotten code, that one day was intended to become an event server until I
> > realized the problems with my approach and stopped doing it (cough,
> > cough).
> 
> 	Ah :-) interesting, can you elucidate as to what the problems were in
> fact Sebastian ? so I suppose we won't put this in ORBit2 yet, it sounds
> somewhat unready :-)

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. 

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.

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).

Bye,
Sebastian
-- 
Sebastian Wilhelmi
mailto:wilhelmi@ira.uka.de
http://goethe.ira.uka.de/~wilhelmi