[Mono-devel-list] About the async sockets issues

[Thomas Harning Jr.]

> Subject:
> Re: [Mono-devel-list] About the async sockets issues
> From:
> Gonzalo Paniagua Javier <gonzalo at ximian.com>
> Date:
> Sun, 17 Apr 2005 15:57:05 -0400
> To:
> mono-devel-list at lists.ximian.com
> 
> To:
> mono-devel-list at lists.ximian.com
> 
> 
> On Sun, 2005-04-17 at 12:15 -0400, Thomas Harning Jr. wrote:
> 
>>Before any people ignore this, I'd first like to ask... does anyone
>>have any examples of using libevent or better documentation?  The docs
>>kinda suck.
>>
>>As soon as my courses are finished for the year and/or perhaps when I
>>get a little time to "relax", I'll work on figuring out how libevent
>>works and try to implement a sockets implementation using that.
>>I will probably create a separate sockets implementation so I don't
>>have to muck around with the mono code each time I make an update....
>>but the code in general will be organized to be able to be put back
>>into Mono.. hopefully. [I'm gonna copy probably the whole
>>System.Net.Sockets directory into something like Eh.Net.Sockets.]
>>
>>Instead of linking against Mono internal calls, I'll have it P/Invoke
>>against a wrapper library around libevent.
>>
>>A quick question... do "internal calls" have the same performance
>>issues as P/Invoke calls?  If I wanted to make things internal calls,
>>how would I go about this?
> 
> 
> Internal calls arguments don't get marshaled.
> 
> 
>>Another thing I found quite desirable in libevent was the buffered
>>event system... basically (as i understand it at the moment):
>>	for socket reads:
>>		1) You set up a buffer of a certain size
>>		2) You call up libevent with the buffer, length, socket to read, and
>>callback (which I believe occurs in the thread that event_dispatch()
>>is called in?.. that would be good for Mono, right, instead of a new
>>thread or signal causing issues...)
> 
> 
> [...]
> 
> [1] Either you have not looked at the code we have now or you're telling
> us what our code does ;-).
> 
> That 1) and 3) is what we do know, but instead of 2) we have a thread
> doint select/poll or epoll_wait.
> 
> 
>>So... for the event handling system using event_dispatch, I would
>>probably have it so that when an event is ready to be handled,
>>depending on what kind it is, spawn a threadpool thread for the user
>>to handle things in.. [for a good system, it'd probably be good for
>>the user to use this callback to queue processing of the events since
>>loads might be received at once].
> 
> 
> See [1] above. But we have a separate threadpool for IO.
> 
> [...]
> 
>>This system might also be good to push into file IO... that still
>>doesn't have very native async IO here yet, or does it?  At the moment
>>I assume it suffers the same as sockets but isn't too big an issue due
>>to file usage/timing is very different from sockets.
> 
> 
> No, it doesn't, but it's very simple to add support for this (< 20 lines
> s of code with comments :-).
> 
> Given that currently we do select/poll on all systems if nothing else is
> available or use epoll if it's there and kqueue support will be added
> sometime soon, we will be lacking support for linux 2.4 RT signal style
> and /dev/poll (oh, and Windows(tm) IOCP), but hopefully someone will
> provide patches for those...
> 
> -Gonzalo
> 
> 
> 

Oh, :-P I guess I shoulda delved deeper into the code and read more.


-- 
Thomas Harning Jr.