number of active process that I see when I run htop

683 views
Skip to first unread message

Sunil S Nandihalli

unread,
May 2, 2011, 5:09:33 AM5/2/11
to golan...@googlegroups.com
Hi everybody,
 I wrote a simple go program which launches about 100 goroutines... I compiled and ran the code and when I ran htop I found way too many (definitely greater 30, I did not count ...) entries of the process I was running. I thought the whole idea of goroutines was to schedule a bunch of goroutines on to a single thread.. (may be two in my case since I am running a dual core machine) .. Am I missing something..?

Thanks,
Sunil.

Sunil S Nandihalli

unread,
May 2, 2011, 5:18:26 AM5/2/11
to golan...@googlegroups.com
I forgot to mention the version of the compiler ..

8g version release.2011-03-07 7666

thanks,
Sunil.

Jan Mercl

unread,
May 2, 2011, 5:30:05 AM5/2/11
to golan...@googlegroups.com
On Monday, May 2, 2011 11:09:33 AM UTC+2, Sunil Nandihalli wrote:
 I wrote a simple go program which launches about 100 goroutines... I compiled and ran the code and when I ran htop I found way too many (definitely greater 30, I did not count ...) entries of the process I was running. I thought the whole idea of goroutines was to schedule a bunch of goroutines on to a single thread.. (may be two in my case since I am running a dual core machine) .. Am I missing something..?

Sounds quite strange. I don't think a Go program can create more/additional OS processes without explicitly being asked to do so. Can you post a minimal compilable example (or a link to it)?

Martin Capitanio

unread,
May 2, 2011, 6:31:36 AM5/2/11
to golan...@googlegroups.com
time.Sleep ?
This issue has been discussed at great length here: 

tux21b

unread,
May 2, 2011, 6:37:50 AM5/2/11
to golang-nuts

On May 2, 11:09 am, Sunil S Nandihalli <sunil.nandiha...@gmail.com>
wrote:
> Hi everybody,
>  I wrote a simple go program which launches about 100 goroutines... I
> compiled and ran the code and when I ran htop I found way too many
> (definitely greater 30, I did not count ...) entries of the process I was
> running.

I'm quite sure, that you are talking about threads, not processes.
(Ok, they
are quite similar on a Linux platform, but they share the same memory
etc.). Press
"H" in htop to hide threads.

> I thought the whole idea of goroutines was to schedule a bunch of
> goroutines on to a single thread.. (may be two in my case since I am
> running a dual core machine) .. Am I missing something..?

Yes, if you do some CPU intensive work, you will probably have just
NUM_CORES
threads.

The really great thing about Go, is that new threads are created
automatically if needed. So, let's
say you are running several Go routines in a single thread. Now, one
of those goroutines does a syscall (e.g. to read a file). Since
syscalls are handled by the kernel, your thread will get blocked until
the kernel has finished the syscall. In the case of several
goroutines, that would mean, that none of them could continue while
the thread is blocked by the kernel. Ouch :/

Luckily, Go creates a new thread as soon another thread gets blocked
by a syscall (unlike node.js), so that you will always have about
NUM_CPUS running (=non-blocking) threads. I do not know your example
program exactly, but I think you might be doing a sleep system call
(which blocks of course), causing your high number of threads. Look at
time.Ticker or time.Timer.AfterFunc to solve such a problem in a non-
blocking manner.

Regards,
Christoph

Sunil S Nandihalli

unread,
May 2, 2011, 9:08:10 AM5/2/11
to golan...@googlegroups.com
It looks like it does create additional threads if one of the goroutines blocks due to system/IO and runs the other goroutines on these new threads.

Thanks,
Sunil.

Namegduf

unread,
May 2, 2011, 9:21:20 AM5/2/11
to golan...@googlegroups.com
On Mon, 2 May 2011 18:38:10 +0530

Sunil S Nandihalli <sunil.na...@gmail.com> wrote:

> It looks like it does create additional threads if one of the
> goroutines blocks due to system/IO and runs the other goroutines on
> these new threads.
>
> Thanks,
> Sunil.

I/O will (generally, I'm not sure if there are exceptions) create a
maximum of one blocked thread, which uses non-blocking I/O as
appropriate to the OS, waking up the appropriate goroutine when it is
done. This makes it cheap to use a goroutine per FD design.

You're right that syscalls in general will block a thread, though.
GOMAXPROCS only affects the number of running threads, not blocked
threads.

a.co...@gmail.com

unread,
Oct 16, 2013, 9:53:35 AM10/16/13
to golan...@googlegroups.com
Reply all
Reply to author
Forward
0 new messages