Frank Church wrote:
OK, I finally got tired of bsods, lockups, illegal ops etc, etc. so I
upgraded to WinXP Home Edition today. So far, what I've seen I like; the
only fly in the ointment seems to be that windows open slower and it takes
noticeably longer to boot up and shut down. I'm used to windows fairly
snapping open with W98 (when it wasn't locked up, etc) I have 512 megs RAM
and an Athlon 1.2 gig processor. Am I gonna have to go to a faster
processor to kick this thing in the butt or what? One small negative in
this whole thing is my scanner software does not work with WinXP..time for
a new scanner I guess.

Since ROFF is now the default source for Windows help, I suppose it's OK
to ask a question about Linux:

Is there a way to call shutdown(blah, SHUT_WR) on a network SOCK_STREAM
connection's fd without discarding pending output? Or some way to block
until pending output has been acknowledged by the far end? (There's a
TCP/IP acknowledgement packet being sent, I'm fairly certain of this...)
I want the connection at the far end to get EOF from read, but still be
able to send me data back from the other half of the connection.
I've looked at the BSD networking documentation, the source code to
"netcat", all the man pages I could find, asked google, etc. The 2.4.18
net/ipv4/tcp.c source has some interesting comments (line 396) about
poll not having a notion of HUP in just one direction, but I've gathered
that select and poll behave differently on files, pipes, network
sockets, block devices, etc... In any case, this doesn't help me find an
exported user-space API that might help me implement this behavior. (By
the way, is "PULLHUP" on lines 414 and 417 a typo for "POLLHUP", or
not?) There doesn't seem to be any variant of a blocking flush() call on
a socket (that I can find), or a way to tell shutdown() to wait for
pending output the way a normal close() does. (Maybe I can do something
fancy with poll or select?) If there IS no way to do this, why does
shutdown(2) bother taking a second argument? (Maybe I can disable nagle
and then do a write of length zero, to make the other end unblock with a
read of length zero and THINK the stream's done? Probably won't work,
but it's worth a try...) (P.S. yes I can rewrite the protocol being sent
over the wire to signal EOF in-band (yet again) but this keeps coming up
over and over. Processes that work when stdin and stdout are seperate
file handles don't work when the data goes back and forth through a
network socket...)

Thanks in advance. :-)

--
Cut "to the chase" for my email address.