hi,
I like a feature that some systems (e.g. Perl) have with respect to
printing to socket streams, where after printing, the stream is
flushed. Is there a way to simply do this? Specifically in
LispWorks.
If there is a simple (non-defadvice) fix, I'm interested. What about
ACL and others? Is there a lower-level (maybe OS) way to do this?
I'm using Linux.
dave
David Bakhash <·····@alum.mit.edu> writes:
> hi,
>
> I like a feature that some systems (e.g. Perl) have with respect to
> printing to socket streams, where after printing, the stream is
> flushed. Is there a way to simply do this? Specifically in
> LispWorks.
>
At which point is the stream flushed? After every character, after
every newline, after every function call that does a print?
> If there is a simple (non-defadvice) fix, I'm interested. What about
> ACL and others? Is there a lower-level (maybe OS) way to do this?
> I'm using Linux.
Both for ACL and LispWorks, there are solution using CLOS and MOP. For
ACL, search for a post by Erik Naggum that created a class at runtime
and used CHANGE-CLASS.
--
Lieven Marchand <···@bewoner.dma.be>
Lambda calculus - Call us a mad club
David Bakhash <·····@alum.mit.edu> writes:
> hi,
>
> I like a feature that some systems (e.g. Perl) have with respect to
> printing to socket streams, where after printing, the stream is
> flushed. Is there a way to simply do this? Specifically in
> LispWorks.
>
> If there is a simple (non-defadvice) fix, I'm interested. What about
> ACL and others? Is there a lower-level (maybe OS) way to do this?
> I'm using Linux.
You should perhaps refine your teminology; What precisely does it mean
to "flush"? What guarantees are you expecting, and what are you willing
to do for such guarantees?
We programmers tend to be program-centric, assuming that if we send data
out, it will get to the destination. But as sockets and larger buffers
are used more and more, this is not necessarily the case (at least, you
have less control of the timing). Some operating systems, including Linux
(as we have found) tend to gather up data in larger packets for sending.
It may be several seconds before the data actually goes out to the
destination.
Even the CL function finish-output, which is specified to not return
until (we think) the data is at the destination, is defined in a way
that includes the word "attempts".
Our resident sockets expert says that the best way to guarantee that the
data actually arrived is to request confirmation from the receiver.
Short of that, one way to be reasonably sure that data got out from a socket
to its destination is to wait 2 seconds, write something else, and if
you didn't get a connection-reset-by-peer, the previous data probably got
to where it was going.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
From: Peter Vaneynde
Subject: Re: autoflush on socket streams
Date:
Message-ID: <6x8zsnh2ur.fsf@lant.be>
Duane Rettig <·····@franz.com> writes:
> We programmers tend to be program-centric, assuming that if we send data
> out, it will get to the destination. But as sockets and larger buffers
> are used more and more, this is not necessarily the case (at least, you
> have less control of the timing). Some operating systems, including Linux
> (as we have found) tend to gather up data in larger packets for sending.
> It may be several seconds before the data actually goes out to the
> destination.
AFAIK This is a feature, not a bug :-).
I think you can switch this on or off per socket.
See SO_SNDBUF in
http://snafu.freedom.org/linux2.2/netman/socket.7.txt
And TCP_NODELAY in
http://snafu.freedom.org/linux2.2/netman/tcp.7.txt
Groetjes, Peter
--
LANT nv/sa, Research Park Haasrode, Interleuvenlaan 15H, B-3001 Leuven
·····················@lant.be Phone: ++32 16 405140
http://www.lant.be/ Fax: ++32 16 404961
Peter Vaneynde <··············@lant.be> writes:
> See SO_SNDBUF in
> http://snafu.freedom.org/linux2.2/netman/socket.7.txt
>
> And TCP_NODELAY in
> http://snafu.freedom.org/linux2.2/netman/tcp.7.txt
Thanks for this catch, Peter; it alerted us to some missing documentation;
The following is available in a fully patched Allegro CL 5.0.1:
for make-socket of :address-family :internet :type :stream there
is an additional extra keyword: :nodelay
:nodelay - normally the network layer will delay sending small packets
of data across the network, hoping that if it waits a bit longer there
will be more data it can include in the packet. By passing a true
value for the :nodelay argument you can turn off this optimization
in the network layer.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Duane Rettig <·····@franz.com> writes:
> The following is available in a fully patched Allegro CL 5.0.1:
>
>
> for make-socket of :address-family :internet :type :stream there
> is an additional extra keyword: :nodelay
yes. that's exactly what I was looking for. It's nice that ACL has
it. I'm not sure the other Lisps have it.
dave