Re: ORBit2 on Win32

["Karl Waclawek" <karl waclawek net>]

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

So the orbit-mt project still has value...
 
> > 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 :-)

AFAIK, the windows sockest can be used in a truly asynchronous way,
i.e. the OS call you back, no polling needed.
 
> > 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.

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

I have RedHat 7.3 at home (dual boot), and I have Cygwin too.
I am not an expert, but used to patch and diff under Cygwin.
I am also using WinCVS.

> > 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;

Now, does this mean you are doing this?
Not being familiar with your code, this would mean
a steep learning curve for me, which I won't be able
to afford (full time job, family with 3 kids - that
doesn't leave that much time - you get the picture).

> Thanks for poking at this, keep asking questions,

I hope that little by little this can be conquered.

Regards,

Karl