Talk:Fiber (computer science)

Merge/refactor?
Fibers are already explained with somewhat more detail on thread (computer science). Maybe fiber (computer science) and thread (computer science) (and possibly computer multitasking) should be refactored? &mdash;Tobias Bergemann 17:29, 18 December 2006 (UTC)
 * 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)
 * 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. &mdash;Tobias Bergemann 10:29, 19 December 2006 (UTC)
 * 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)
 * 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)

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)
 * 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)

Similar to green thread?
How do they relate to green threads? Seems to be the same to me.24.203.136.86 (talk) 18:00, 14 March 2008 (UTC)postsigned
 * 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)
 * 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)
 * 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)
 * 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)
 * 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)
 * 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)
 * 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)
 * "Greenlets" are identical to what is described in this article: http://codespeak.net/py/dist/greenlet.html ; The article might also benefit from a mention of Protothreads: http://www.sics.se/~adam/pt/ —Preceding unsigned comment added by 174.146.134.148 (talk) 17:22, 1 February 2009 (UTC)
 * 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)

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)
 * 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)
 * 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)

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)
 * 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)

Threads can be co-operative
The first line says "However, fibers use co-operative multitasking while threads use pre-emptive multitasking.". Threads can be co-operatively multitasked as well (though I accept its not that common now days). See for example https://en.wikipedia.org/wiki/Thread_(computing) (under scheduling): "Operating systems schedule threads either preemptively or cooperatively" or the classic http://mirror.informatimago.com/next/developer.apple.com/documentation/macos8/pdf/ThreadManager.pdf

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)


 * 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)