This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: More details about the tmux 2.0 regression
- From: Äsmail DÃnmez <ismail at donmez dot ws>
- To: cygwin at cygwin dot com
- Date: Mon, 8 Jun 2015 18:25:59 +0300
- Subject: Re: More details about the tmux 2.0 regression
- Authentication-results: sourceware.org; auth=none
- References: <CAJ1KOAidxNn99KCUNHCbGCvOc=51vz8uzo5zag_0FEYj-yyFPQ at mail dot gmail dot com> <20150608124159 dot GE3005 at calimero dot vinschen dot de> <20150608132103 dot GJ3005 at calimero dot vinschen dot de> <CAJ1KOAiz8rV33jmCuLHj9pkLBD+3w3N+7+eEQ6cZwScAkcsNyg at mail dot gmail dot com>
On Mon, Jun 8, 2015 at 6:12 PM, Äsmail DÃnmez <ismail@donmez.ws> wrote:
> On Mon, Jun 8, 2015 at 4:21 PM, Corinna Vinschen
> <corinna-cygwin@cygwin.com> wrote:
>> On Jun 8 14:41, Corinna Vinschen wrote:
>>> On Jun 6 12:58, Äsmail DÃnmez wrote:
>>> > Hi,
>>> >
>>> > I had a nice discussion with tmux maintainers over at
>>> > https://github.com/tmux/tmux/issues/13 about the tmux 2.0 regression
>>> > on Cygwin.
>>> >
>>> > Long story short, tmux is trying to read /proc/<pid>/cmdline and
>>> > /proc/<pid>/cwd for various reasons and for non-Cygwin programs this
>>> > is quite slow. You can reproduce this easily run cmd.exe inside bash
>>> > and try to
>>> >
>>> > cat /proc/<pid of cmd.exe>/cmdline
>>>
>>> Good catch!
>>>
>>> The problem here was that this functionality is very Cygwin centric. It
>>> tries to call into the process itself to fetch the information.
>>>
>>> E.g, assuming you have some /proc/1234, it tries to fetch the information
>>> by sending a request to process 1234 and then waits for that process
>>> setting a semaphore. A non-Cygwin process will obviously fail to do so,
>>> not knowing about the method at all.
>>>
>>> I fixed that in the Cygwin git repo and it seems to work much better now
>>> to run native tools inside tmux with this change.
>>>
>>> I'll upload a developer snapshot on https://cygwin.com/snapshots/ later
>>> today.
>>
>> Snapshot is up.
>
> That resolves the problem for me, cheers!
One question though, would it be possible to return executable name
instead of <defunct> for non-Cygwin processes?
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple