Hmm, what if getaddrinfo was used directly as an extern proc in the Net
module code instead of through a wrapper in sys.c? Though that would be
an issue on systems without a getaddrinfo. We'd be able to handle that
if it was possible to have conditional compilation of Chapel code
depending on the OS type. Is there a pragma for that?
Go's net package provides a pretty intuitive high-level way to do
connect and listen without all the low-level structures and call
sequences. Connecting looks like net.Dial("tcp", "example.com:8080") and
listening looks like net.Listen("tcp", "127.0.0.1:8080"). You pass
strings, and all the low-level DNS lookup, socket binding, and
translation to system-specific constants and whatnot is hidden. Dial
returns a Conn, which you can read and write to directly and use
wherever a Reader or Writer is expected, while Listen returns a Listener
with an Accept() which returns Conns. Access to the low level stuff is
still provided, but these functions are generally all you need.
I imagine Chapel's net package would have similar facilities, and maybe
let you pass URL strings for convenience. It would be nice to connect to
a web server with net_connect("tcp://example.com:80") or even
net_connect("http://example.com";) and have it return a channel (or pair
of). Similarly, net_listen will let you specify a bind address in the
URL and return an object which has an accept() method that returns channels.
It would be nice to offer some expressive flexibility and sensible
defaults with regard to accepted URL formats for these functions. E.g.,
net_listen("tcp://0.0.0.0:80"), net_listen("tcp://:80"),
net_listen("0.0.0.0:80"), and net_listen(":80") should be equivalent.
Using a different socket type is as easy as changing the URL, e.g.
net_listen("udp://:80"), net_listen("unix:/path/to/socket"),
net_listen("raw://:80"). net_connect and net_listen would of course be
overloaded to let you pass the arguments separately, e.g.,
net_connect("tcp", "example.com:80") or net_connect("tcp",
"example.com", 80) as well. Ideally it should be as easy as possible to
hack together a working network application and incrementally optimize
it with lower-level library functions (which will of course be provided
as well) as necessary.
I just finished a simple URL parser for this purpose, which is the
reason behind the string-oriented patch I submitted. Even if we opt not
to use URLs for describing network connections, it's always nice to have
a good URL parser in a networking package. (At least it's something I'm
always looking for.)
-- Brandon
On 12/02/2013 05:36 PM, Michael Ferguson wrote:
> Hi -
>
> Yes, we commented out getaddrinfo because we were getting warnings
> in testing and didn't want to spend much time chasing them
> down since nobody was using that functionality. So I'd recommend
> you un-comment it and sorting out the portability problem will
> become worth doing (whether you or somebody else does it). As Brad's
> comment says - it was triggering a warning in some Cray environments...
> (not a fatal error). It's not clear to me that using a different
> function would solve the warning... it's really a build issue.
> The warning we are talking about is something like
> warning: Using 'getaddrinfo' in statically linked applications
> requires at
> runtime the shared libraries from the glibc version used for linking
> We could:
> - decide to ignore the warning
> - try to disable the warning
> - try to limit the warning to cases when getaddrinfo is actually used
> (with some form of conditional compilation, inlining, or maybe
> putting it in a "net support file" that is only included when
> requested)
> - investigate if there's a way to build differently to avoid
> the warning. For example, maybe we don't really need to statically
> link?
> Or maybe there is some other magic linker flag to solve the problem?
>
> I'm not familiar with Go's net package. Could you briefly describe how
> Go-inspired network functions in Chapel might look to a user?
>
> Also, it's important to understand the existing I/O design
> which separates a 'file' (e.g. something storing data on disk) from
> a 'channel' (buffered, unidirectional I/O). You can't read or write
> a 'file' directly in Chapel - you must open a 'channel' first. The
> reason is that we wanted to avoid the race condition inherent in
> the pre-threads UNIX design which has a file position stored in a
> file. So we store the file position in a 'channel', which cannot
> seek, and addresses a defined portion of a file. Different channels
> can be openned to the same file and don't have to have immediate
> visibility into each others I/Os (vs how writes to a FILE* must
> be immediately available for reading). Anyway, I'm probably
> belaboring this point, but accept and connect would return channels,
> not files, in Chapel.
>
> An IRC channel might be a good idea, but there isn't one now.
> It might make it shorter to respond to questions, when we don't
> have to set the record for posterity...
>
> (to do atoi, cast a string containing a number to an integer).
>
> -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
