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

[Thomas Harning Jr.]

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?

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...)
		3) You deal with the callbacks that show up when you have data.

	for socket writes:
		1) You set up a buffer of a certain size
		2) You call up libevent with the buffer, length of buffer, socket to write, and callback
		3) You deal with the callbacks that show up when your buffer is empty (which would be when you start maybe?   I doubt you'd wanna send the whole buffer at the start)

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

The buffered event system would be very good for handling socket streams nicely so you keep the buffer fill of data instead of blocking and/or dealing with a new spawned thread just because you want async.


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.
-- 
Thomas Harning Jr.