A portable high-level socket library like Boost.Asio or apache MINA

Yang Bo Joined: 09/16/07 Posts: 9

Posted: 09/21/07 03:28:28 Modified: 09/21/07 03:31:42 Yes, there is tango.io.selector.Selector. But it is very slow, and many limits(not support file io, only 64 sockets) on Windows. And the implement of epoll/select is just a wrapper on C functions. I think a portable high-level socket library is needed, such a high-level library can hide the different model of each platform.

Author	Message
Yang Bo Joined: 09/16/07 Posts: 9	Posted: 09/21/07 03:42:07 Boost.Asio and apache MINA are very different, but both of them are high level and platform neutrality. I prefer Boost.Asio because it is more flexible.
kris Joined: 03/27/04 Posts: 581	Posted: 09/21/07 03:51:06 That would be great! I'd love to see that too :)
Yang Bo Joined: 09/16/07 Posts: 9	Posted: 09/21/07 06:46:34 -- Modified: 09/21/07 06:54:18 by Yang Bo -- Modified 2 Times Now I think a library like Boost.Asio is not best solution for portable high-level socket. The model of Boost.Asio is very like IOCP on Windows, and it make select and epoll works as IOCP. IOCP is very easy to implement handler per operation, but epoll and select is not. Forcing epoll and select work like IOCP is ineffective. For example, Boost.Asios calls epoll_ctl when every I/O operation start or complete, and it is unwanted if the user do not need handler per operation.
r.lph50 Joined: 11/27/06 Posts: 21	Posted: 09/21/07 11:53:22 Umm, just curious, but did this old announcement: larsivi wrote: Further on, we're building an asynchronous I/O library based on Tango's IO abstractions with notifications sent on completion of I/O events. ever get started by anyone? Or was it just a "someday we'll get around to it". Not that I feel any right to the work, just that whole announcement sounded so cool. And in the interim I've tried to get my head around the proactor model and fibers in preparation :)
larsivi Joined: 03/27/04 Posts: 614	Posted: 09/21/07 12:09:08 It is started alright, but I fear it is coming in rather late.
r.lph50 Joined: 11/27/06 Posts: 21	Posted: 09/26/07 05:57:41 Would it be of any use to have a tango.devel project?
kris Joined: 03/27/04 Posts: 581	Posted: 09/26/07 06:01:06 I think that's what tango.scrapple is for?
r.lph50 Joined: 11/27/06 Posts: 21	Posted: 09/28/07 08:25:28 Oh. I understood scrapple to be, working but homeless. Whereas I was wondering if there was a place for the projects that have been announced by the 'mainstream' tango but are still being worked on. But perhaps the developers prefer to work in privacy.
larsivi Joined: 03/27/04 Posts: 614	Posted: 09/28/07 08:47:32 It all depends on the developer :) I believe the I/O stuff guy uses a local Monotone repository until things are usable.
r.lph50 Joined: 11/27/06 Posts: 21	Posted: 10/31/07 01:26:29 I've just finished Uni for the year (until who know when), and I have some free time. Is there anything I can do to help get an asynchronous I/O library working with tango?
kris Joined: 03/27/04 Posts: 581	Posted: 10/31/07 06:35:07 -- Modified: 10/31/07 06:42:25 by kris What I'd really like to see is the kqueue model for Tango. One which we can use for a variety of things. It truly sucks that Linus decided to go with something less capable, but perhaps the model can be adapted to work with linux? The main benefit of kqueue is that a client does not have to deal with a threaded model at all. Asynchronous events are queued up, like mouse or keyboard events, and processed by the application when it gets around to it. This is a huge feature for most people, since (as we all know) threading is seriously prone to subtle error.
r.lph50 Joined: 11/27/06 Posts: 21	Posted: 10/31/07 09:41:59 I felt sad at the demise of Evgeniy Polyakov's kevent On kqueue & linux LWN has: There are, evidently, real reasons for not replicating the kqueue interface, but those reasons have not, yet, been made clear.
kris Joined: 03/27/04 Posts: 581	Posted: 11/01/07 00:41:58 maybe over concerns about maintaining queues in the kernel space? With Tango, that would all be in user-space, and would be configurable on an app-by-app basis