Re: ORBit2 on Win32

[Michael Meeks <michael ximian com>]

Hi Karl,

On Tue, 2002-09-17 at 14:12, Karl Waclawek wrote:
> > Not really; we have put a fair bit of work into making sure it can be
> > multi-threaded, but we havn't tested it / finished it. Ultimately my
> > feeling is that the asynchronous model is far superior and more
> > maintainable - but then - we don't have full server side async support
> > yet either ;-) so ...
> 
> Are we talking about the same thing? I meant support for the different
> threading models, like thread per connection & thread pool.

	Yes - we don't support that.

> With asynchronous model, do you mean: overlapped I/O and such things?

	Yes, inasmuch that when you would do a bit of blocking IO instead, you
store state, and poll for input / output / handle that. Currently we
have simple re-enterant event processing, which gives some of the
benefits of the async model, but we could have more :-)

> Yes, that makes sense. In theory - if you have async - you probably
> need a multi-processor server to take advantage of threads.

	Depends on the setup; but threads have a largish performance overhead
in contrast to the async model IMHO, and are significantly more
confusing.

> You have to consider that I don't know much about the
> commonly used libraries on Unix.

	Fair enough, nor do I :-), do you have an account on a Unix system
where you can read man pages and compare fixes / builds ? if not, one
can be procured for you.

> The old ORBit Win32 port has some WinSock stuff - is that something
> that could be re-used here?

	Interesting - we need to integrate with the glib mainloop (the polling
mechanism), I don't think glib1 did that. But if we can poll on those
handles, then yes fine. It's possible we want a custom IO handler inside
linc-protocols.c or somesuch [ assuming we can read/write on a windows
socket ? ]. Also, we rather rely on doing non-blocking I/O, I imagine we
should only copy the glib1 bits if we need to;

	Thanks for poking at this, keep asking questions,

	Regards,

		Michael.

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