[Top][All Lists]

[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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]