Upstart spins forever when sender fails to call recv()

[upstart at eehouse.org]

I've been looking at a problem on an embedded system that uses
upstart.  An app is using libupstart, calling nih_io_message_send() to
send upstart a message (an emit, I think) to which upstart expects to
reply.  The app, however, never calls nih_io_message_recv(); rather,
it drops the socket on the floor in effect.  Upstart then spins
forever trying to reply.  It gets ECONNREFUSED back from sendmsg()
every time, but because the socket keeps coming back writable from
select() it keeps trying.

I understand that the app is mistaken in dropping the socket.  But I'm
getting some pressure to modify upstart to close the socket when this
happens so we're less vulnerable to errors like this.  Are there good
reasons to keep the socket open in this case?  (We're on 0.3.8 thanks
to our build system having a really old autoconf, but the latest code
seems the same: errors from sendmsg() are noted but not otherwise
acted on.)

Thanks,

--Eric
-- 
******************************************************************************
* From the desktop of: Eric House, eehouse at eehouse.org                       *
*       Crosswords 4.4 for WinMobile plays over the internet: xwords.sf.net  *
******************************************************************************