[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Emacs-diffs] master d805757: Fix a subtle problem in Tramp with tim
From: |
Michael Albinus |
Subject: |
Re: [Emacs-diffs] master d805757: Fix a subtle problem in Tramp with timers |
Date: |
Wed, 01 Feb 2017 16:26:39 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) |
Stefan Monnier <address@hidden> writes:
Hi Stefan,
>> + ;; FIXME: There are problems, when an asynchronous process runs in
>> + ;; parallel, and also timers are active. See
>> + ;; <http://lists.gnu.org/archive/html/tramp-devel/2017-01/msg00010.html>.
>
> Hmm... this thread doesn't seem to have an explanation of the problem.
> It basically has a recipe to reproduce a problem, but that's about it.
> Do we know what is the underlying problem? It sounds nasty and it might
> be worth trying to (additionally) fix it "right" directly in Emacs.
I've played with this for days, and at least I'm happy to nail it down
to that code.
I don't know the real problem yet, and I also failed to extract a simple
test case I could give somebody else for analysis. Will continue, but
I'm running out of ideas how to simplify the recipe, and how to make it
reproducible w/o knowing Tramp internals.
>> + (when (and timer-event-last
>> + (string-prefix-p "*tramp/" (process-name proc))
>
> Why not do something like (process-get proc 'tramp-<something>) instead of
> testing its name?
Good idea. Will check whether I could simplify the test.
>> + (let (result)
>> + (maphash
>> + (lambda (key _value)
>> + (and (processp key)
>> + (not (string-prefix-p "*tramp/" (process-name key)))
>> + (tramp-compat-process-live-p key)
>> + (setq result t)))
>> + tramp-cache-data)
>> + result))
>> + (sit-for 0.01 'nodisp))
>
> The thread linked does mention that (sit-for 0.01 'nodisp) circumvents
> the problem, but I see no explanation for the condition you use around
> it (all that tramp-cache-data and timer-event-last business).
Yep, better comments will serve. But OTOH I don't expect it to be the
final solution, it is just something I could arrange for running
properly in this edge case. There might be even other constellations the
error happens in a similar way.
>> ;; Under Windows XP, accept-process-output doesn't return
>> - ;; sometimes. So we add an additional timeout.
>
> I see this is not new, but here as well, it sounds like something that
> we should fix in Emacs. Did you report the problem? Does it have a bug#?
> Is it fixed in recent Emacsen? If so, which versions are affected?
This is something completely different. According to the ChangeLog, the
timeout and the comment were added 2006-12-10. It could be even that it
was XEmacs specific, don't remember.
I'll add this to my todo list for checking. Or we simply deactivate the
timeout, and wait for people protesting. I cannot test it myself
comprehensively, because I don't use MS Windows machines, usually.
> Stefan
Best regards, Michael.