On Tue, Jun 20, 2017 at 07:56:09PM -0700, Kevin J. McCarthy wrote: > On Tue, Jun 20, 2017 at 09:13:54PM -0500, Derek Martin wrote: > > Why block the signal? Why not just handle EINTR when connect() > > returns? > > During a few searches, > http://www.madore.org/~david/computers/connect-intr.html turned up, > which implied handling EINTR for connect is not a simple affair: you > have to select/poll instead of just being able to re-call.
Wow, that's dreadful. I had no idea--I've only written network code on Linux, which behaves more sanely. You could instead close the socket and set it up again... > My main concern was in mutt_block_signals() [signal.c], where the > code for the SIGWINCH was surrounded by the #if. [...] But I didn't > understand why the need to be conditional in mutt_block_signals(). Right, I get that, I was just approaching the problem from a different angle. I usually prefer to avoid changing portable programs around signal handling, partly because different platforms can behave differently (as here, with connect()), and partly because in my experience no one ever gets signal code right... ;-) I don't have a copy of the code handy and need sleep desperately, otherwise I'd try to take a more serious shot at answering your question... -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience.
pgpLAUxwhkJr9.pgp
Description: PGP signature
