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
On 12/02/2013 03:14 PM, Brandon Ross wrote:
> 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
