Bash doesn't launch the applications directly.

Bash doesn't launch the applications directly.

[Lenik]

Hi, all

I noticed that when bash launches a program, for example win32 notepad.exe 
or cygwin sleep, it in fact launches another bash which launches the final 
program,

# sleep 10
-> running process:
  bash          (start here)
    bash
      sleep 10

This slows down the launching procedure.
Any idea?

Lenik 



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Bash doesn't launch the applications directly.

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Lenik on 1/14/2009 5:59 PM:
> Hi, all
> 
> I noticed that when bash launches a program, for example win32
> notepad.exe or cygwin sleep, it in fact launches another bash which
> launches the final program,
> 
> Any idea?

Yes.  It's called forking (a concept that Windows does not have natively,
but which cygwin does a LOT of work to emulate).  The way Unix apps
(including bash) start another program is to first fork themselves, then
in that fork, exec the target program.  The fork accounts for the second
bash process.

Depending on the nature of the called process, you might also see those
additional processes stick around.  If the child is a cygwin process (like
sleep), exec() is decently emulated, where the forked bash goes away and
you are left with only one running sleep process.  But if it is a windows
process (like notepad), cygwin has to insert a shim process in between to
handle signal handling in order to abort notepad if you type ctrl-c in
bash, as well as collect the correct exit status.

Ultimately, bash could be made faster by using posix_spawn() instead of
fork(), for much of what it does.  However, that would require 1) an
upstream patch to bash to use posix_spawn(), including a fallback
implementation of posix_spawn on platforms that don't yet implement it
(such an implementation is possible, since gnulib already provides one,
but the upstream maintainer is hard to convince, and even if the patch
existed, it has already missed the bash 4.0 cutoff), and 2) an
implementation of posix_spawn() in cygwin that directly spawns processes
using native Windows concepts (the bash fallback implementation of
posix_spawn() would still end up using fork() under the hood, giving no
speedups until we have a native version).  http://cygwin.com/acronyms/#PTC

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@byu.net
volunteer cygwin bash maintainer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklvNLsACgkQ84KuGfSFAYBp7wCfdPswFfp5U+1fsNAU2cIRDwGF
UGsAoLhOPK3JdM/E61ruig0Ji5a1yJkY
=C9qK
-----END PGP SIGNATURE-----

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Bash doesn't launch the applications directly.

[Dave Steenburgh]

On Thu, Jan 15, 2009 at 8:06 AM, Eric Blake <ebb9@byu.net> wrote:
> According to Lenik on 1/14/2009 5:59 PM:
>> Hi, all
>>
>> I noticed that when bash launches a program, for example win32
>> notepad.exe or cygwin sleep, it in fact launches another bash which
>> launches the final program,
>>
>> Any idea?
>
> Yes.  It's called forking (a concept that Windows does not have natively,
> but which cygwin does a LOT of work to emulate).  The way Unix apps
> (including bash) start another program is to first fork themselves, then
> in that fork, exec the target program.  The fork accounts for the second
> bash process.
>
> Depending on the nature of the called process, you might also see those
> additional processes stick around.  If the child is a cygwin process (like
> sleep), exec() is decently emulated, where the forked bash goes away and
> you are left with only one running sleep process.  But if it is a windows
> process (like notepad), cygwin has to insert a shim process in between to
> handle signal handling in order to abort notepad if you type ctrl-c in
> bash, as well as collect the correct exit status.

Well, now I understand why I occasionally see more instances of bash
in the task manager than I was expecting.  However, now I have to ask
why the shim doesn't appear [plainly] with ps:

     4540       1    4540       4540    0 1003 11:48:08 /usr/bin/bash
     5656    4540    5656       4756    0 1003 11:48:35
/cygdrive/f/WINDOWS/system32/notepad

5656 is the PID of the shim, and 4756 is the PID of notepad.  I'm
extrapolating here, so correct me if I'm wrong: whenever the WINPID
column is different from the PID column, there's a shim process?  The
task manager displays both, because they are after all separate
processes.  Personally, I'd rather see one entry for each process than
have to notice when PID and WINPID are different.  Out of curiosity,
what would ps show if somehow the shim was left running long after
notepad had exited?  Would you still see notepad, or would there be no
entry at all, or would the shim then be in plain sight?

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Bash doesn't launch the applications directly.

[Christopher Faylor]

On Thu, Jan 15, 2009 at 12:11:30PM -0500, Dave Steenburgh wrote:
>Well, now I understand why I occasionally see more instances of bash
>in the task manager than I was expecting.  However, now I have to ask
>why the shim doesn't appear [plainly] with ps:
>
>     4540       1    4540       4540    0 1003 11:48:08 /usr/bin/bash
>     5656    4540    5656       4756    0 1003 11:48:35
>/cygdrive/f/WINDOWS/system32/notepad

Because that's the way ps works.  It shows cygwin pids.  If you really
want to see the shim process you do have to use the task manager.

>5656 is the PID of the shim, and 4756 is the PID of notepad.  I'm
>extrapolating here, so correct me if I'm wrong: whenever the WINPID
>column is different from the PID column, there's a shim process?

No, that's not correct.  WINPID can be unequal to PID in other situations
too.  That's because the Windows API doesn't have anything like exec*().

>The task manager displays both, because they are after all separate
>processes.  Personally, I'd rather see one entry for each process than
>have to notice when PID and WINPID are different.  Out of curiosity,
>what would ps show if somehow the shim was left running long after
>notepad had exited?  Would you still see notepad, or would there be no
>entry at all, or would the shim then be in plain sight?

You are asking for postulation on an event that should never occur but
if the shim still exists cygwin's ps will probably think that there is
still a process with that cygwin pid sitting around.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Bash doesn't launch the applications directly.

[L Anderson]

Christopher Faylor wrote:
> On Thu, Jan 15, 2009 at 12:11:30PM -0500, Dave Steenburgh wrote:
>> Well, now I understand why I occasionally see more instances of bash
>> in the task manager than I was expecting.  However, now I have to ask
>> why the shim doesn't appear [plainly] with ps:
>>
>>     4540       1    4540       4540    0 1003 11:48:08 /usr/bin/bash
>>     5656    4540    5656       4756    0 1003 11:48:35
>> /cygdrive/f/WINDOWS/system32/notepad
> 
> Because that's the way ps works.  It shows cygwin pids.  If you really
> want to see the shim process you do have to use the task manager.

If you want to get a much better picture of what's happening, do:

0. Task Manager--forgid-da-boud-dit! It's so, "just barely"!

1. Download, install, & start "Process Explorer v11.32" (procexp.exe) from:

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

2. Bring up a Cygwin shell and execute "notepad" -- leave them be.

3. Bring up another Cygwin shell and execute "ps"

Now you can see the various Cygwin process'/shim relationships and 
attributes, graphically, in "Process Explorer" and how the PIDs n WIDS n 
such from the "ps" listing relate.

It's pretty cool!

Lowell Anderson


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Bash doesn't launch the applications directly.

[Lenik]

"Eric Blake" <ebb9@byu.net> 写入消息 news:496F34BB.6080200@byu.net...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> According to Lenik on 1/14/2009 5:59 PM:
>> Hi, all
>>
>> I noticed that when bash launches a program, for example win32
>> notepad.exe or cygwin sleep, it in fact launches another bash which
>> launches the final program,
>>
>> Any idea?
>
> Yes.  It's called forking (a concept that Windows does not have natively,
> but which cygwin does a LOT of work to emulate).  The way Unix apps
> (including bash) start another program is to first fork themselves, then
> in that fork, exec the target program.  The fork accounts for the second
> bash process.
>
> Depending on the nature of the called process, you might also see those
> additional processes stick around.  If the child is a cygwin process (like
> sleep), exec() is decently emulated, where the forked bash goes away and
> you are left with only one running sleep process.  But if it is a windows
How fast does the emulation implemented?

> process (like notepad), cygwin has to insert a shim process in between to
> handle signal handling in order to abort notepad if you type ctrl-c in
> bash, as well as collect the correct exit status.
Is there any option to disable the shim process?

I have tried to launch notepad in background:
  # calc &
In such situation, we won't ever press ctrl-c or ctrl-z, (maybe until fg 
%1), but there still got 2 bash processes. If I just want to send the launch 
signal to win32, and don't care what if user press ctrl-c in the bash.

I tried `cygstart `which notepad`', this did launch another bash, too (while 
it launches cygstart.exe and which.exe additionally). Though the cygstart 
and shim are then immediately terminated, but it cost the launching time.

>
> Ultimately, bash could be made faster by using posix_spawn() instead of
> fork(), for much of what it does.  However, that would require 1) an
> upstream patch to bash to use posix_spawn(), including a fallback
> implementation of posix_spawn on platforms that don't yet implement it
> (such an implementation is possible, since gnulib already provides one,
> but the upstream maintainer is hard to convince, and even if the patch
> existed, it has already missed the bash 4.0 cutoff), and 2) an
> implementation of posix_spawn() in cygwin that directly spawns processes
> using native Windows concepts (the bash fallback implementation of
> posix_spawn() would still end up using fork() under the hood, giving no
> speedups until we have a native version).  http://cygwin.com/acronyms/#PTC
>
Is it possible to make cygstart as a bash built-in? And thus will get 
another benefit that after cygstart.exe terminated, the parent-children 
relationship between the bash and notepad can be maintained.

Lenik 



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Bash doesn't launch the applications directly.

[Mark J. Reed]

On Thu, Jan 15, 2009 at 8:59 PM, Lenik wrote:
> Is it possible to make cygstart as a bash built-in?

I think you might misunderstand the relationship between Cygwin and
bash.  Bash is not a part of Cygwin.  It is a standalone shell,
written to run on any UNIX-like platform: Linux, Solaris, OS X, BSD,
etc.  Apart from some minor compile-time conditional code that's
Cygwin specific, parallel to similar platform-specific code for other
environments, bash is not modified at all for the Cygwin environment.
The whole point of Cygwin is to allow programs written for UNIX to
compile and run under Windows - and bash is just one such program.

Since bash was written for UNIX, it uses the UNIX mechanism for
launching another process.  Cygwin does the best it can to make that
mechanism work on Windows, but it's not very efficient because that's
not the way Windows is designed.  Still, adding Cygwin-specific code
to bash is not the answer, if only because the upstream bash team is
unlikely to provide any help supporting such a patch.  Maintaining
something like that in the face of upstream changes is a significant
challenge that the (tiny!) Cygwin team doesn't have the resources for.

As Eric said, the only major changes in the direction of improved
performance that one might be able to convince the bash folks to make
is to add support for the new POSIX spawn interface, but bash has its
own roadmap with its own goal, and if posix_spawn() is even on the
list it's a ways in the future.  In any case, adding it won't do any
good until the Cygwin team also adds that interface to Cygwin, but
there's little incentive to add it to Cygwin until it's supported by
bash... sort of a chicken and egg problem on the motivation front.

If I may ask, what are you doing that is causing this to be a
significant performance problem for you?

-- Mark

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/