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
On 11/30/2013 04:12 AM, Brandon Ross wrote:
> Hello all,
>
> I saw you guys at SC13 and fell in love with all of the nice async and
> parallel features Chapel had to offer. I see the language is still in
> its early stages, so I thought I'd make a side project out of
> contributing some code and helping to beef up Chapel's standard library
> a bit.
>
> Chapel seems to be lacking in its networking support, so I figured I'd
> start out there. I'm thinking about putting together a cross-platform
> DNS resolver over the weekend. Is anyone else working on network support
> right now? I don't want to end up doing redundant work.
>
> Anyway, looking forward to getting to know the community.
>
> -- Brandon
>
> ------------------------------------------------------------------------------
> 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
>
------------------------------------------------------------------------------
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
