[m-rev.] for review: improvements to net/tcp.m

[Ian MacLarty]

On Wed, Mar 28, 2007 at 05:05:39PM +1000, Julien Fischer wrote:
> 
> On Wed, 28 Mar 2007, Peter Ross wrote:
> 
> >On Wed, Mar 28, 2007 at 03:50:36PM +1000, Peter Wang wrote:
> >>Improvements to the tcp module.
> >>
> >>extras/net/tcp.m:
> >>	Make tcp an instance of the `reader' typeclass with unit `string' and
> >>	implement line reading efficiently in C.
> >>
> >>	Do input buffering on sockets so it's not necessary to call recv() 
> >>	for
> >>	each character read.
> >>
> >>	Delete `is_eof' predicate.  This is no longer needed due to the 
> >>	change
> >>	in the way characters are read.
> >>
> >>	Add predicates tcp__ignore_sigpipe and tcp__unignore_sigpipe to 
> >>	ignore
> >>	SIGPIPE signals that are sent if writing to a broken socket.  
> >>	Disabling
> >>	SIGPIPE allows write calls to return an error code instead of 
> >>	aborting
> >>	the process.
> >>
> >>	Fix an incorrect `will_not_call_mercury' annotation on
> >>	`handle_shutdown'.
> >>
> >>	Fix memory leaks caused by calling MR_NEW instead of MR_GC_NEW.
> >>
> >>
> >>Index: tcp.m
> >>===================================================================
> >>RCS file: /home/mercury1/repository/mercury/extras/net/tcp.m,v
> >>retrieving revision 1.1
> >>diff -u -r1.1 tcp.m
> >>--- tcp.m	16 Nov 2006 04:01:49 -0000	1.1
> >>+++ tcp.m	28 Mar 2007 05:41:41 -0000
> >>@@ -57,11 +57,23 @@
> >>
> >> :- instance input(tcp, io.state, tcp.error).
> >> :- instance reader(tcp, character, io.state, tcp.error).
> >>+:- instance reader(tcp, string, io.state, tcp.error).
> >>
> >You should state what sort of strings are read?
> >Until a new line, for something else.
> >
> >It appears to be until a new line, you should state this and state
> >that the newline is in the string.
> 
> Actually you should probably define:
> 
> 	:- type line ---> line(string).
> 
> and use that in instance instead of just a raw string.  We were
> planning to add something like the above to the io module anyway,
> so it may be a good time work out the details.
> 

What about giving a block size when you initialize the tcp socket
and then having stream.get/4 return strings of this length?

Breaking the data up on lines seems a bit arbitrary to me.  It's
possible that there are no line breaks in the data, which means it will
all be read into one big string, which could be a performance problem.
If you allow a block size to be given, then the user has more control
over the size of strings that are returned.

Ian.
--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------