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

[Gonzalo Paniagua Javier]

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