This article is within the scope of WikiProject Computer science, a collaborative effort to improve the coverage of
Computer science related articles on Wikipedia. If you would like to participate, please visit the project page, where you can join
the discussion and see a list of open tasks.Computer scienceWikipedia:WikiProject Computer scienceTemplate:WikiProject Computer scienceComputer science articles
This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of
computers,
computing, and
information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join
the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
This article is within the scope of WikiProject Linux, a collaborative effort to improve the coverage of
Linux on Wikipedia. If you would like to participate, please visit the project page, where you can join
the discussion and see a list of open tasks.LinuxWikipedia:WikiProject LinuxTemplate:WikiProject LinuxLinux articles
This article is within the scope of WikiProject Microsoft Windows, a collaborative effort to improve the coverage of
Microsoft Windows on Wikipedia. If you would like to participate, please visit the project page, where you can join
the discussion and see a list of open tasks.Microsoft WindowsWikipedia:WikiProject Microsoft WindowsTemplate:WikiProject Microsoft WindowsMicrosoft Windows articles
Not merge; they're different concepts with some confusion of vocabulary. (Fibers are strictly cooperatively multitasked, and so don't need to worry about
thread safety etc.) Some degree of refactoring might help, I guess; what are you suggesting? --
EdC 00:51, 19 December 2006 (UTC)reply
Hm. I really don't know. As you wrote, there appears to be some confusion of vocabulary. I am not sure I understand the difference between fibers and
coroutines, and I only ever have heard the term fiber used in the context of Microsoft Windows. So I would say: Either merge
fiber (computer science) back into
thread (computer science) (or perhaps
coroutines), or add some references for the usage of the term fiber, or add some description of the Windows API. —
Tobias Bergemann 10:29, 19 December 2006 (UTC)reply
Well, I've taken the latter two options; I don't really know the Windows API all that well (though it appears fairly straightforward) but have linked into MSDN. I think the distinction is – at the level of the Windows API certainly – that coroutines are a technique, while fibers are a facility. --
EdC 01:30, 24 December 2006 (UTC)reply
No, the difference is that "coroutine" is a long-standing computer science term and "fiber" is a Windows buzzword for market differentiation ("look at this cool new feature guys!"). This page is just a Microsoft shill masquerading as "computer science". It should probably be reduced into a 1-2 sentence summary and be merged in the coroutine article. — Preceding
unsigned comment added by
82.9.176.129 (
talk) 10:17, 27 October 2013 (UTC)reply
Similar to continuation?
There is an article on
Continuation. Fibers appear to be very similar to continuations. If they are the same, perhaps the articles should be merged. If they are not the same, then perhaps a reference and some distinctions should be added to the article.
Kevin99 18:06, 21 February 2007 (UTC)reply
Fibers can be implemented using continuations, but not the other way around. Continuations are essentially a first-class object containing the current state of a fiber - but can be invoked more than once (or not at all). Schemers frequently implement fibers this way using a few lines of code, in fact.
Anaholic (
talk) 10:12, 7 December 2007 (UTC)reply
Green threads are a
virtual machine construct; fibers are provided by the operating system and/or C library. Also, green threads try to appear as much as possible like "real" threads to the running code, while fibers have to be scheduled explicitly.
EdC (
talk) 13:53, 16 March 2008 (UTC)reply
Thank you. If I understand correctly, threads are different because blocking calls don't affect other threads; fibers are different because you must explicitly yield; green threads are different because they are not system calls but application code (and this I have difficulties wrapping my head around as it isn't obvious where the system ends and where the application begins).
Also, from
threads: "SunOS 4.x implemented "light-weight processes" or LWPs as fibers known as green threads" seems to imply green threads are fibers. It may be I haven't dug enough. If that is the case, I'll refrain from commenting until I've had time to master those finer points.
70.81.152.109 (
talk) 19:52, 19 March 2008 (UTC)reply
Theoretically, you could have preëmption of green threads by hacking around with signals I suppose, but in practice green threads and fibers are the same thing. For example, I remember with early versions of Java it was important to yield() from time to time in long-running computations in order to give other threads a chance to execute. If someone were to propose merging the green threads page with this one, I'd support it.
Donal Fellows (
talk) 08:49, 1 February 2009 (UTC)reply
But fibers don't have a yield() method, just a yieldToOtherFiber() method. I.e. with fibers you have to schedule them yourself, while green thread can be seen by the programmer just like other kinds of threads. Sure you can tinker green threads and then get preemption, just like you can use kernel threads and signals to build preemptable user threads... —Preceding
unsigned comment added by
SamuelThibault (
talk •
contribs) 23:18, 6 February 2009 (UTC)reply
You're right. In that case, they're clearly
coroutines (specifically, they are a coroutine support framework for C, at least one of the linked references acknowledges this, and it's pretty clear from the references that “coroutine” is the senior term) and this article should be merged with that instead. Why Microsoft had to create a new term — fiber — rather than using an existing one, I really don't know. Nor care.
Donal Fellows (
talk) 21:00, 8 February 2009 (UTC)reply
Then I propose to merge the OpenMP and Threads articles :) To my mind, the difference between coroutines and fibers is that coroutines are a language thing while fibers are a library thing. As shown in the coroutine article, coroutines would be implemented _above_ fibers, and people wouldn't think of doing the converse (just like nobody would implement PThreads on top of OpenMP even if it is possible). Coroutines can also be implemented above something else than fibers, see Simon Tatham's implementation for instance. —Preceding
unsigned comment added by
SamuelThibault (
talk •
contribs) 09:59, 9 February 2009 (UTC)reply
The real issue is that, although ‘fiber’ is linked from lots of pages (as part of a template for topics in parallel computing), there seems to be no proper literature for the term that I can see (using Google Scholar to search). By contrast, there is a respectable literature for ‘coroutine’. All the indication is that Microsoft invented the term from scratch for the Win2k API. Hence that template perhaps ought to link to
coroutine, and that page should in turn link to this one as part of a discussion of implementations.
Donal Fellows (
talk) 13:35, 10 February 2009 (UTC)reply
Greenlets is just the name of a implementation of coroutines. This page is purporting to be a "computer science" concept, when it's actually just Microsoft's cynically "branded" name for what are essentially coroutines. I honestly don't think Microsoft coming up with a buzzword for an already existing concept warrants it's own article. I could just be a mention of the coroutine page. — Preceding
unsigned comment added by
82.9.176.129 (
talk) 10:20, 27 October 2013 (UTC)reply
Fiber vs Fibre
I disagree with removing the fibre term. Right, it's a UK word. But UK people would look for it. Note that I haven't reverted the utilise->utilize because there it is indeed just a matter of US vs UK style. But when it comes to glossary, we should really provide both UK and US words. —Preceding
unsigned comment added by
SamuelThibault (
talk •
contribs) 10:04, 9 February 2009 (UTC)reply
Then they'll find it on the Fiber disambiguation page. —Preceding
unsigned comment added by
70.130.236.56 (
talk) 02:00, 26 February 2009 (UTC)reply
So have it in one place (first paragraph) and then consistently use one or the other the rest of the time. Given the origin of this whole terminology according to what I could scare up on the web seems to be the US — and it is only in that form that it is used in APIs — that's what should be the senior term on this page.
Donal Fellows (
talk) 09:06, 26 February 2009 (UTC)reply
Motion to delete
I would like to gather consensus to remove this article. As mentioned numerous times above, this concept already has a name -- "coroutine" -- which has been around for a very long time and has a great deal of academic literature behind it. "Fiber" is essentially Microsoft's re-branded name for coroutines. It's deserving of a small mention on the coroutine page at best. It certainly doesn't warrant it's own article, masquerading as a fundamental "computer science" concept. Opinions?...
Agree completely. This concept has long been known as a coroutine, and there is no reason to allow well-established computer science terminology to fall prey to the marketing strategy of
Embrace_extend_extinguish. — Preceding
unsigned comment added by
106.138.69.184 (
talk) 06:19, 15 May 2014 (UTC)reply
Disagree completely. Coroutines were initially done in the assembler and acted like generalized functions per Knuth, Conway. Later in the presence of higher-level languages coroutines were emulated by fibers (user mode stack switching even though the term Fiber did not exist, that was effectively what they were doing). Fibers can be used to emulate coroutines, but fibers and coroutines are not the same. — Preceding
unsigned comment added by
73.53.38.236 (
talk) 01:31, 12 October 2015 (UTC)reply
Off the top of my head I would say the difference is that there is only ever one fibre running at a time - something not guaranteed for threads - but I don't know if that is really the distinguishing feature so I haven't yet made the change. — Preceding
unsigned comment added by
Cqexbesd (
talk •
contribs) 13:28, 19 April 2017 (UTC)reply
I came here to say the exact same thing. The definition of a thread has nothing to do with how it is scheduled. — Preceding
unsigned comment added by
192.31.106.34 (
talk) 15:14, 26 February 2018 (UTC)reply
This article is within the scope of WikiProject Computer science, a collaborative effort to improve the coverage of
Computer science related articles on Wikipedia. If you would like to participate, please visit the project page, where you can join
the discussion and see a list of open tasks.Computer scienceWikipedia:WikiProject Computer scienceTemplate:WikiProject Computer scienceComputer science articles
This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of
computers,
computing, and
information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join
the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
This article is within the scope of WikiProject Linux, a collaborative effort to improve the coverage of
Linux on Wikipedia. If you would like to participate, please visit the project page, where you can join
the discussion and see a list of open tasks.LinuxWikipedia:WikiProject LinuxTemplate:WikiProject LinuxLinux articles
This article is within the scope of WikiProject Microsoft Windows, a collaborative effort to improve the coverage of
Microsoft Windows on Wikipedia. If you would like to participate, please visit the project page, where you can join
the discussion and see a list of open tasks.Microsoft WindowsWikipedia:WikiProject Microsoft WindowsTemplate:WikiProject Microsoft WindowsMicrosoft Windows articles
Not merge; they're different concepts with some confusion of vocabulary. (Fibers are strictly cooperatively multitasked, and so don't need to worry about
thread safety etc.) Some degree of refactoring might help, I guess; what are you suggesting? --
EdC 00:51, 19 December 2006 (UTC)reply
Hm. I really don't know. As you wrote, there appears to be some confusion of vocabulary. I am not sure I understand the difference between fibers and
coroutines, and I only ever have heard the term fiber used in the context of Microsoft Windows. So I would say: Either merge
fiber (computer science) back into
thread (computer science) (or perhaps
coroutines), or add some references for the usage of the term fiber, or add some description of the Windows API. —
Tobias Bergemann 10:29, 19 December 2006 (UTC)reply
Well, I've taken the latter two options; I don't really know the Windows API all that well (though it appears fairly straightforward) but have linked into MSDN. I think the distinction is – at the level of the Windows API certainly – that coroutines are a technique, while fibers are a facility. --
EdC 01:30, 24 December 2006 (UTC)reply
No, the difference is that "coroutine" is a long-standing computer science term and "fiber" is a Windows buzzword for market differentiation ("look at this cool new feature guys!"). This page is just a Microsoft shill masquerading as "computer science". It should probably be reduced into a 1-2 sentence summary and be merged in the coroutine article. — Preceding
unsigned comment added by
82.9.176.129 (
talk) 10:17, 27 October 2013 (UTC)reply
Similar to continuation?
There is an article on
Continuation. Fibers appear to be very similar to continuations. If they are the same, perhaps the articles should be merged. If they are not the same, then perhaps a reference and some distinctions should be added to the article.
Kevin99 18:06, 21 February 2007 (UTC)reply
Fibers can be implemented using continuations, but not the other way around. Continuations are essentially a first-class object containing the current state of a fiber - but can be invoked more than once (or not at all). Schemers frequently implement fibers this way using a few lines of code, in fact.
Anaholic (
talk) 10:12, 7 December 2007 (UTC)reply
Green threads are a
virtual machine construct; fibers are provided by the operating system and/or C library. Also, green threads try to appear as much as possible like "real" threads to the running code, while fibers have to be scheduled explicitly.
EdC (
talk) 13:53, 16 March 2008 (UTC)reply
Thank you. If I understand correctly, threads are different because blocking calls don't affect other threads; fibers are different because you must explicitly yield; green threads are different because they are not system calls but application code (and this I have difficulties wrapping my head around as it isn't obvious where the system ends and where the application begins).
Also, from
threads: "SunOS 4.x implemented "light-weight processes" or LWPs as fibers known as green threads" seems to imply green threads are fibers. It may be I haven't dug enough. If that is the case, I'll refrain from commenting until I've had time to master those finer points.
70.81.152.109 (
talk) 19:52, 19 March 2008 (UTC)reply
Theoretically, you could have preëmption of green threads by hacking around with signals I suppose, but in practice green threads and fibers are the same thing. For example, I remember with early versions of Java it was important to yield() from time to time in long-running computations in order to give other threads a chance to execute. If someone were to propose merging the green threads page with this one, I'd support it.
Donal Fellows (
talk) 08:49, 1 February 2009 (UTC)reply
But fibers don't have a yield() method, just a yieldToOtherFiber() method. I.e. with fibers you have to schedule them yourself, while green thread can be seen by the programmer just like other kinds of threads. Sure you can tinker green threads and then get preemption, just like you can use kernel threads and signals to build preemptable user threads... —Preceding
unsigned comment added by
SamuelThibault (
talk •
contribs) 23:18, 6 February 2009 (UTC)reply
You're right. In that case, they're clearly
coroutines (specifically, they are a coroutine support framework for C, at least one of the linked references acknowledges this, and it's pretty clear from the references that “coroutine” is the senior term) and this article should be merged with that instead. Why Microsoft had to create a new term — fiber — rather than using an existing one, I really don't know. Nor care.
Donal Fellows (
talk) 21:00, 8 February 2009 (UTC)reply
Then I propose to merge the OpenMP and Threads articles :) To my mind, the difference between coroutines and fibers is that coroutines are a language thing while fibers are a library thing. As shown in the coroutine article, coroutines would be implemented _above_ fibers, and people wouldn't think of doing the converse (just like nobody would implement PThreads on top of OpenMP even if it is possible). Coroutines can also be implemented above something else than fibers, see Simon Tatham's implementation for instance. —Preceding
unsigned comment added by
SamuelThibault (
talk •
contribs) 09:59, 9 February 2009 (UTC)reply
The real issue is that, although ‘fiber’ is linked from lots of pages (as part of a template for topics in parallel computing), there seems to be no proper literature for the term that I can see (using Google Scholar to search). By contrast, there is a respectable literature for ‘coroutine’. All the indication is that Microsoft invented the term from scratch for the Win2k API. Hence that template perhaps ought to link to
coroutine, and that page should in turn link to this one as part of a discussion of implementations.
Donal Fellows (
talk) 13:35, 10 February 2009 (UTC)reply
Greenlets is just the name of a implementation of coroutines. This page is purporting to be a "computer science" concept, when it's actually just Microsoft's cynically "branded" name for what are essentially coroutines. I honestly don't think Microsoft coming up with a buzzword for an already existing concept warrants it's own article. I could just be a mention of the coroutine page. — Preceding
unsigned comment added by
82.9.176.129 (
talk) 10:20, 27 October 2013 (UTC)reply
Fiber vs Fibre
I disagree with removing the fibre term. Right, it's a UK word. But UK people would look for it. Note that I haven't reverted the utilise->utilize because there it is indeed just a matter of US vs UK style. But when it comes to glossary, we should really provide both UK and US words. —Preceding
unsigned comment added by
SamuelThibault (
talk •
contribs) 10:04, 9 February 2009 (UTC)reply
Then they'll find it on the Fiber disambiguation page. —Preceding
unsigned comment added by
70.130.236.56 (
talk) 02:00, 26 February 2009 (UTC)reply
So have it in one place (first paragraph) and then consistently use one or the other the rest of the time. Given the origin of this whole terminology according to what I could scare up on the web seems to be the US — and it is only in that form that it is used in APIs — that's what should be the senior term on this page.
Donal Fellows (
talk) 09:06, 26 February 2009 (UTC)reply
Motion to delete
I would like to gather consensus to remove this article. As mentioned numerous times above, this concept already has a name -- "coroutine" -- which has been around for a very long time and has a great deal of academic literature behind it. "Fiber" is essentially Microsoft's re-branded name for coroutines. It's deserving of a small mention on the coroutine page at best. It certainly doesn't warrant it's own article, masquerading as a fundamental "computer science" concept. Opinions?...
Agree completely. This concept has long been known as a coroutine, and there is no reason to allow well-established computer science terminology to fall prey to the marketing strategy of
Embrace_extend_extinguish. — Preceding
unsigned comment added by
106.138.69.184 (
talk) 06:19, 15 May 2014 (UTC)reply
Disagree completely. Coroutines were initially done in the assembler and acted like generalized functions per Knuth, Conway. Later in the presence of higher-level languages coroutines were emulated by fibers (user mode stack switching even though the term Fiber did not exist, that was effectively what they were doing). Fibers can be used to emulate coroutines, but fibers and coroutines are not the same. — Preceding
unsigned comment added by
73.53.38.236 (
talk) 01:31, 12 October 2015 (UTC)reply
Off the top of my head I would say the difference is that there is only ever one fibre running at a time - something not guaranteed for threads - but I don't know if that is really the distinguishing feature so I haven't yet made the change. — Preceding
unsigned comment added by
Cqexbesd (
talk •
contribs) 13:28, 19 April 2017 (UTC)reply
I came here to say the exact same thing. The definition of a thread has nothing to do with how it is scheduled. — Preceding
unsigned comment added by
192.31.106.34 (
talk) 15:14, 26 February 2018 (UTC)reply