发生系统调用阻塞的时候切换到另外一个goroutine运行,此时另一个goroutine是新建一个线程运行么?GOMAXPROC设置的线程数具体是指什么?默认单线程的时候是怎么处理goroutine的切换的?谢谢!!
--
来自: Golang-China ~ 中文Go语言技术邮件列表
发言: golang...@googlegroups.com
详情: http://groups.google.com/group/golang-china
官网: http://golang-china.org/
翻译: http://github.com/border/golang-china/
论坛: http://bbs.golang-china.org/
@golangchina
Goroutine的协调管理是go语言的核心机制,是由编译器具体调控的,对程序员来说是透明的,我们只要认为或相信它内部一定会运作的很好就可以了。综合现有信息来看,goroutine机制设计的很理想,但目前编译器的实现上还不是很完美,有许多需要改进和完善的地方,会越来越好;就算目前的实现也大概足够实用(有人评估过吗)。如果对goroutine内部管理/调控/运作机制感兴趣,可以研究下go语言编译器源代码(go语言目前有两个编译器,内部实现也不一样)。
--
�Dz���ʹ���̳߳ز�֪������gccgo��ȷ��һ��goroutineһ���̡߳�����Go1�
�����ģ��Ͳ�����ˡ���ӡ���к���Go1�ļƻ����д�����gccgo��5/6/8gͳһ
�ġ���֪�����������������ͱ���ͳһ�������ڲ�ʵ��Ҳ����ͳһ�������
˵�������˾��û���5/6/8g���
>
> 3��Ϊʲô GOMAXPROCS>1 ������ʱ������� http://weekly.golang.org/doc/go_faq.html#Why_GOMAXPROCS
>
> ����ժ¼��Go's goroutine scheduler is not as good as it needs to be. In future, it should recognize such cases and optimize its use of OS threads. For now, GOMAXPROCS should be set on a per-application basis.
> �������룺Go �� goroutine ��������û�дﵽԤ��Ŀ�ꡣ��������Ӧ�Զ�ʶ����Щ��������Ż��̵߳�ʹ�á����ڣ�����ֻ���ֹ����� GOMAXPROCS ��
�����е����壺For now, GOMAXPROCS should be set on a per-application
basis. ��÷���Ϊ��Ŀǰ��GOMAXPROCS����Ӧ�ø��Ӧ�ó���ĸ���������ֱ�
����
> --------------
> wonderfo
>> ����ϵͳ�����л�goroutine����һ���л��������̡߳��л��ĵ�λ��Э�̣��� windows �½� fiber��
>>
>> 2012/1/24 ������<hong...@gmail.com>
>>
>>> ����ϵͳ���������ʱ���л�������һ��goroutine���У���ʱ��һ��goroutine���½�һ���߳�����ô��
>>> GOMAXPROC���õ��߳��������ָʲô��Ĭ�ϵ��̵߳�ʱ������ô����goroutine���л��ģ�
>>>
>>> лл����
>>>
>>> --
>>> ����: Golang-China ~ ����Go���Լ����ʼ��б�
>>> ����: golang...@googlegroups.com
>>> ����: http://groups.google.com/group/golang-china
>>> ����: http://golang-china.org/
>>> ����: http://github.com/border/golang-china/
>>> ��̳: http://bbs.golang-china.org/
>>> @golangchina
>>>
>>
>>
>>
>> --
>> ��ʽΰ
>> https://qbox.me
>>
>> --
>> ����: Golang-China ~ ����Go���Լ����ʼ��б�
>> ����: golang...@googlegroups.com
>> ����: http://groups.google.com/group/golang-china
>> ����: http://golang-china.org/
>> ����: http://github.com/border/golang-china/
>> ��̳: http://bbs.golang-china.org/
>> @golangchina
>
�� 2012/1/30 13:13, wonderfo �:
> ̸�������⣬��֪�Ƿ�������ʵ�ԭ�壺
>
> �����ʵ��ĽǶȣ������������ȷʵ�Dz����������й�����Դ����Ӧ���� chan �趨������Դ�ķ��ʴ��� �������ҹ淶
> ���о�����ĽǶȣ�GOMAXPROC=1 ʱ�������Ƿ��ܱ�֤��Դijʱ�̵�Ψһ���ʣ��Ҹ��˲�֪����û�о���ô���ˡ�
>
> --------------
> wonderfo
>> �̶�GOMAXPROC=1��ʱ����Ҫ������
>>
>> 2012/1/27 wonderfo <wond...@yeah.net>
>>
>>> �Ǻǣ�лл monnand ָ��(^_^)
>>>
>>> ���⣬���� fango �IJ��ģ�������е���ʾ���ҵ�Դ�ļ� proc.c�������о�ע����֤�� ������ ���뷨��$GOMAXPROCS
>>> ȷʵֻ�����ʹ�ú��ĵĽ���ֵ��
>>>
>>> $GOMAXPROCS is thus an approximation of the maximum number of cores to use.
>>>
>>>
>>> --------------
>>> wonderfo
>>>> wonderfo wrote, On 01/25/2012 10:41 PM:
>>>>> �� FAQ �п��������Ŀ��û�������о����ԣ����˴��Է��루Ӣ��ɼ����ã��������������λͬѧָ��
>>>>>
>>>>> 1��Ϊʲôʹ�� goroutines �����߳�
>>> http://weekly.golang.org/doc/go_faq.html#goroutines
>>>>> ժ¼��When a coroutine blocks, such as by calling a blocking system call,
>>> the run-time automatically moves other coroutines on the same operating
>>> system thread to a different, runnable thread so they won't be blocked.
>>> ��ǿ����һ��Эͬ��������ʱ���������һ�������ϵͳ���ã���ͬһ�߳��µ�����Эͬ���ᱻ��Go����ʱ���Զ����ȵ���һ���������̣߳�����Ͳ��ᱻ�����ˡ�
>>>>> ժ¼��To make the stacks small, Go's run-time uses segmented stacks. A
>>> newly minted goroutine is given a few kilobytes, which is almost always
>>> enough. When it isn't, the run-time allocates (and frees) extension
>>> segments automatically. The overhead averages about three cheap
>>> instructions per function call. It is practical to create hundreds of
>>> thousands of goroutines in the same address space. If goroutines were just
>>> threads, system resources would run out at a much smaller number.
>>> ���룺Ϊ����ջ�ռ�ռ�ã���Go����ʱ��ʹ�÷ֶ�ջ���½���goroutine�ȷ��伸KBջ�ռ䣬���ڴ����������Ѿ����á����ջ�ռ䲻������Go����ʱ������䣨���ͷţ�����ջƬ�Ρ��������ƽ��ʹ��3����ָ������ʵ���У�����ͬ��ַ�ռ䴴����ʮ��
>>> goroutines �ǿ��еġ����ʹ���̣߳�����ϵͳ��Դ�����ƣ����֮�������� goroutines �����ٺܶࡣ
>>>>>
>>>>> 2��Ϊʲô�ҵĶ�goroutine����û�г�����ö�CPU
>>> http://weekly.golang.org/doc/go_faq.html#Why_no_multi_CPU
>>>>> ժ¼��Under the gc compilers you must set GOMAXPROCS to allow the run-time
>>> support to utilise more than one OS thread. Under gccgo an OS thread will
>>> be created for each goroutine, and GOMAXPROCS is effectively equal to the
>>> number of running goroutines.
>>>>> ���룺�� gc �������£���������� GOMAXPROCS ���?Go����ʱ��ʹ�ö���̡߳��� gccgo �������£�ÿ�� goroutine
>>> ���ᴴ��һ���̣߳�GOMAXPROCS ������е� goroutine ����
>>>>> ������Under gccgo an OS thread will be created for each goroutine
>>> Ӣ�IJ��ã���仰������ɻ���Ϲ�£���gccgo���Dz����������̳߳صĻ��ƣ������� gorouitne ѽ������ÿ�� goroutine
>>> ����һ���̣߳����̫���˰ɣ�����һ����Ŀ����˼Ҳ����ѽ���е��Ժ�����λͬѧָ��
>>>> �Dz���ʹ���̳߳ز�֪������gccgo��ȷ��һ��goroutineһ���̡߳�����Go1�
>>>> �����ģ��Ͳ�����ˡ���ӡ���к���Go1�ļƻ����д�����gccgo��5/6/8gͳһ
>>>> �ġ���֪�����������������ͱ���ͳһ�������ڲ�ʵ��Ҳ����ͳһ�������
>>>> ˵�������˾��û���5/6/8g���
>>>>> 3��Ϊʲô GOMAXPROCS>1 ������ʱ�������
>>> http://weekly.golang.org/doc/go_faq.html#Why_GOMAXPROCS
>>>>> ժ¼��Go's goroutine scheduler is not as good as it needs to be. In
>>> future, it should recognize such cases and optimize its use of OS threads.
>>> For now, GOMAXPROCS should be set on a per-application basis.