[MUD-Dev] Sockets

[Jon A. Lambert]

On 9 May 99,, Chris Gray wrote:
> 
> The WIN32 interface in particular is one which essentially forces the
> programmer to use multiple threads. 

There is no NEED to use multiple threads in Win32.  Non-blocking sockets
perform exactly like their BSD counterparts,

> Consider the "asynchronous I/O"
> features available. You can use their completion routines stuff, but they
> aren't really asynchronous because they are only triggered when some
> I/O related system call completes (e.g. a poll). You can use their
> interface which sends a message on call completion, but for that you
> have to have an active window, which is something a MUD server (or http
> server or ftp server, etc.) is not likely to want. 

Yes. This is true.  Asynchronous sockets require you to use the Windows 
messaging system.  Thus they cannot be used from a console application.
And that's why I ranked this method third in performance.  Yet it still
performs much better than non-blocking.  Comparing this particular 
mechanism with anything on *nixes is useless, since it doesn't exist.

> for that, WaitForMultipleObjects, has a fixed, hard limit of 64 handles
> that it can wait on. If you want more than that, you have to either
> start polling (ugh!) or have multiple threads, each waiting for groups
> of handles. 

Polling (ugh!)?  But aren't you doing that in your non-blocking sockets 
apps?  I can't imagine using WaitForMultipleObjects handles in this 
manner.  This is the same (or worse because of the limitation) as single-
threaded non-blocking sockets.  That is, it would be a "poor" 
implementation.  I use WaitForMultipleObjects on two handles.  One is on 
the socket input event and one is on the muds output work queue.  The 
thread is fired when data arrives on the socket OR when data arrives on 
the output queue.   If I ever need to deal with huge amounts of 
connections I can pool multiple sockets and work queues to threads.  I 
don't know what the "huge" number would be yet; 100?, 200?, 500?, 1000?
 
> So, I agree, that if you are programming under the WIN32
> API, you will get better performance by using threads than if you
> didn't, but *that is a result of the nature of the API, rather than any
> inherent advantage of threads*.

I KNOW that threading I/O  performs better on Win32.  
The question is "Does threading I/O perform better on Linux/BSD?"
    
If someone would ACTUALLY DO IT in Linux/BSD, perhaps the question could 
be answered rather than theorized at.


--
--*     Jon A. Lambert - TychoMUD Email:jlsysinc at ix.netcom.com             *--
--*     Mud Server Developer's Page <http://pw1.netcom.com/~jlsysinc>      *--
--* To fight the empire is to be infected by its derangement. Whosoever    *--
--* defeats part of the empire becomes the empire; it proliferates like a  *--
--* a virus... thereby it becomes its enemies." -- P.K. Dick               *--


_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev