[9fans] name resolution

[9fans] name resolution

[Richard Uhtenwoldt]

>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!)

Re: [9fans] name resolution

[Joel Salomon]

> | in Linux, probably because of glibc, a web browser (well, only tested
> | with Lynx) doing a domain-name lookup cannot be interrupted by the
> | "stop button" (more precisely, the "z" key in Lynx).
>
> 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.
>
Pressing "z" sends a signal?
Lynx is pretty good with "z" during other operations - I'd guess that
under *n!x socket connection is harder to mulithread (?) - I got the same
result under ScumOS.

> | I'm wondering if Plan 9 has the same restriction/property.
The Plan 9 browser has no bugs. ☺

> 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.
Coool!!!

--Joel

Re: [9fans] name resolution

[Scott Schwartz]

| in Linux, probably because of glibc, a web browser (well, only tested
| with Lynx) doing a domain-name lookup cannot be interrupted by the
| "stop button" (more precisely, the "z" key in Lynx).

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.

| I'm wondering if Plan 9 has the same restriction/property.

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.

[9fans] name resolution

[Richard Uhtenwoldt]

in Linux, probably because of glibc, a web browser (well, only tested
with Lynx) doing a domain-name lookup cannot be interrupted by the
"stop button" (more precisely, the "z" key in Lynx).

so, if you mistakenly follow a link and the name server takes 10
seconds to respond, the "stop button" in particular and the browser in
general freezes for 10 seconds.

I'm wondering if Plan 9 has the same restriction/property.