Hi Michael, Yup, I saw those. I put together a little test module to try it out, but the getaddrinfo wrapper is commented out in sys.c citing compile-time error messages, and setting up the structures for bind is awkward otherwise, which is why I thought to tackle DNS resolution first. I'd like to hide as much of the socket-bind-listen dance as possible and make it feel a little more like how Go's net package does it.
I'm planning on providing interfaces to make stream sockets usable anywhere files are expected. To start, connect and accept might actually just return a file object wrapping the socket descriptor and the Net module can decorate file with some additional socket-specific methods, and we'll see how that works. I'm not sure what we can do about datagram sockets. It would be nice to support the notion of connected datagram sockets that can be used like a file, while also providing "datagram-y" methods to allow them to be used as such. I have some ideas, but I'll have to think about it a little more. By the way, is there an IRC channel or somewhere I can hang out to ask small questions (e.g., where is Chapel's atoi equivalent?) that aren't mailing list-worthy? If not, I think one would be really nice. -- Brandon On 12/02/2013 10:01 AM, Michael Ferguson wrote: > Hi Brandon - > > Great idea! When I implemented the current I/O system, I included > many functions for networking in sys.h, sys.c, and Sys.chpl. So > a good way to start would be to look there, figure out what is already > working, fix it if necessary, and then create friendly Chapel module > code for it. > > What I'd really like to see is that network connections > (at least TCP) are normally programmed using the existing read/write > calls in Chapel. It's OK if we need to change which system calls > perform the reading or writing (and I can offer some help there if > you are able to describe what you need it to do), but it is possible to > use 'read' and 'write' system calls with a connected TCP socket, which > the I/O system should be able to do now. What we're missing (for TCP > at least), > from a Chapel programming view, is: > - functions like 'accept' and 'connect' that generate reader and writer > channels (I'd make them return 2 channels). (Note that it is possible > to open up a channel with a file descriptor, so you should be able to > build this out of existing functions in Sys.chpl and sys.c if > everything > works as expected). > - functions for DNS resolution > - a same or different interface for UDP or connection-less networking > - unit tests in Chapel to test the networking functionality > > Lastly, one of my long-standing desires has been to write a network > server in Chapel using qthreads to demonstrate that with user-level > tasks, it is possible to get the performance of an 'event-driven' > server with simple code written as 1-task-per-connection. What should > happen now with qthreads is: > - task waits for new connections > - spawns new task for each connection > - new task waits for input/output > - calls in sys.c or wrapped by qthreads cause blocking I/O call > (like read/write/send/recv) to move to a separate pthread, > so any ready work in a different task can be done by the worker > thread. > > I have a long-standing desire incorporate libevent, so that for > networking > or other potentially long-delay I/O operations, instead of moving to a > 'worker pthread', the blocking operation would be handled internally > using > callbacks that mark the task doing the I/O as ready. Let me know if you > are interested in tackling that project later on, and I would be happy > to show you what code would need to change. > > Cheers, > > -michael ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk _______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
