From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Subject: [9fans] name resolution From: Richard Uhtenwoldt Message-Id: Date: Thu, 18 Sep 2003 10:21:17 -0700 Topicbox-Message-UUID: 3d09ae5e-eacc-11e9-9e20-41e7f4b1d025 >Nah, if the program isn't event driven, a signal still ought to be able >to interrupt the syscall. Lynx probably just doesn't bother. that's right: during a name resolution in Lynx, sig intr (^c) and sig susp (^z) have their usual effect: namely, sig intr kills the Lynx. because the ftp command does so, it is almost certain that Lynx _could_ have a handler (terminology?) that customizes the behavior of sig intr. in particular, if ftp is blocked on a name lookup, sig intr gets you right back to the command prompt. but like you say they did not bother. >Plan 9 has a much better bug: if a fileserver doesn't answer 9p messages, >a communicating process blocked in read/write never gets unblocked and >can't be killed with a signal. Sigh. I'm curious whether _that_ is because no one has bothered (to fix it) or because previous design and implementation decisions make fixing it really awkward. if a fileserver doesn't answer 9p messages, can a signal (note) kill the _parent_ of the blocked process? can the parent be made to handle a signal by killing the child? (I hope that's clear!)