[MUD-Dev] Re: async i/o and threads (was: Re: lurker emerges

[Jon A. Lambert]

On 11 Aug 98, James Wilson wrote:
> From: Jon A. Lambert <jlsysinc at ix.netcom.com>
> 
> > What is the mingw32 system?
> 
> MINimal GNU Win32. It's a cutdown of the whole GnuWin32 package,
> which is hefty and bloated and evil, but to my mind far preferable to
> borland, msvc++, etc. I spit on their crappy IDEs, ptui!
> mingw32:
> <url http://agnes.dida.physik.uni-essen.de/~janjaap/mingw32/index.html>
> gnuwin32:
> <url http://www.cygnus.com/misc/gnu-win32/>
>

Ok.  The Cygnus implementation of sockets is somewhat suspect.  All 
other concerns to the side, Cygnus recommends that WIN32 socket 
natives be used in preference to their sockets emulation.  There is a 
great deal of overhead in the Unix emulation (obviously!).  Also, 
Cygnus has in the past found (and often fixed) many an error in this 
area.  There does exist an ability to mix and match Cygus GNU 
libraries with native windows calls.  If there is a portability 
issue, the use of winsock is usually a comfortable port to Linux as 
Linux is to other flavors of Unix.  

Also winsock and winsock2 offer a number of interesting and useful 
features (non-portable, of course), which are theoretically relevant 
to the blocking/non-blocking discussion at hand.  Like 
WSAAsyncSelect(), WSASetBlockingHook(), etc.  Of course, such a 
discussion would not provide any immediate practical value to 
Unix programming.

>From what I can glean from the web pages,  the Minimal GNU Win32 
library simply provides a wrapper to winsock natives.  You might
achieve the same level portability results with some minimal 
conditional compilation (at least in the sockets area).  I'd would 
"guess" that read() and write() are mapped to recv() and send() 
since win32 does not attach file handles to sockets.   Thus there is 
likely an abstraction layer that handles file handles to allow 
redirection of select()?  hmm... 

> > > I'm a bit concerned about the overhead of using a thread pool, though,
> since
> > > my two
> > > target platforms (win32 and linux) use heavyweight threads. Has anyone
> tried
> > > a bytecode vm that implements user-level threads, setting up a scheduler
> > > that timeslices between 'processes', switches context on blocking i/o,
> and
> > > so on? Maybe this could give you lightweight, portable threading while
> > > keeping the whole process in a single thread? I'm imagining something
> where
> > > the main thread is either chomping bytecode or checking for io-ready
> > > sockets.
> >
> > Aye .  I believe MUQ does exactly this.  Many of the programable
> > servers impose execution limits on internal tasks (i.e. Cold, LP)
> 
> 
> hmmm... this sounds promising. I'll poke around and see what I can find.
> can anyone comment on the pros and cons of such an approach?

There are some old links on this.  2nd or 3rd Qtr 97.  Look for 
"Threads" in subject line and/or author "Cybne ru Taren" (sp?).

<OT>
As far as the stuff about compiler and mailer preferences, I think 
it's pretty irrelevant to the discussion.  And I care not to go 
there.  
</OT>
--
--/*\ Jon A. Lambert - TychoMUD     Internet:jlsysinc at ix.netcom.com /*\--
--/*\ Mud Server Developer's Page <http://www.netcom.com/~jlsysinc> /*\--
--/*\   "Everything that deceives may be said to enchant" - Plato   /*\--