[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reducing the sit-for time in w3m-process-wait-process
- From: David Engster <deng@xxxxxxxxxxxxxxx>
- Date: Fri, 05 Dec 2008 14:41:00 +0100
- X-ml-name: emacs-w3m
- X-mail-count: 10514
- References: <87vdu5tscu.fsf@xxxxxxxx> <8763m1j5xy.fsf@xxxxxxxx> <b4m4p1jauok.fsf@xxxxxxx> <87tz9j5785.fsf@xxxxxxxxxxxxxxxxxxxxxxx>
TSUCHIYA Masatoshi <tsuchiya@xxxxxxxxxx> writes:
>>> To followup on this: I sometimes got parsing errors with '(sit-for
>>> 0.1)', because the buffer didn't contain the whole output from the w3m
>>> binary. However, I could fix this by using accept-process-output in the
>>> w3m sentinel. Now everything works without problems, and the reduced
>>> sit-for time makes working with emacs-w3m faster. Before, a w3m call
>>> would at least take one second, even when w3m just received a redirect
>>> or was fetching a small picture for a shimbun article. I attached the
>>> two-lines patch to this mail.
>
>>Great! I verified that the patch makes shimbun fast beyond
>>recognition for fetching articles containing many images. David,
>>could you provide the ChangeLog entry?
>
> I worry that the following change causes hang-up.
> I had tried various values when implementing w3m-proc.el, and adpoted
> the smalest value that did not cause hang-up of emacs.
> Of course, the ideal value may depend on users' own enviroments.
> I have no idea to decide the ideal value in safe way.
Yes, I have occasionally observed those deadlocks when using very small
values (like 0.01) in the sit-for command. I'd also guess it depends on
the speed of the machine Emacs is running on.
I agree that it is difficult to say which value could be considered
safe. I've so far not encountered hang-ups with 0.1 on three different
machines I'm using, but that surely is a small sample. :-)
If this issue cannot be resolved, I would suggest to rewrite this, at
least for shimbun retrieval, by just calling w3m asynchronously with a
sentinel and without a handler. I freely admit though that I don't
really understand the purpose of using this handler for calling the w3m
binary. It seems to me it is just used to see if the process takes
longer than what is given in w3m-process-timeout? I would argue that
timeouts should be handled by the binary itself. I didn't find a timeout
option for w3m, but it seems to me it has a built-in timeout which is
way smaller than the default 5 minutes of w3m-process-timeout anyway (I
would guess about 30 seconds?). Please correct me if I'm mistaken here
and the handler also has some other purpose I didn't notice.
Regards,
David