On Aug 13, 2010, at 5:38 PM, Ernest N. Prabhakar, Ph.D. wrote:
> Hi Scott,
>
> On Aug 13, 2010, at 1:46 PM, easco wrote:
>>> Remember, nobody is defending the POSIX pthread APIs here, they're saying
>>> that GCD makes Fibers less relevant...
>>
>> GCD makes Fibers less relevant so long as you
Hi Scott,
On Aug 13, 2010, at 1:46 PM, easco wrote:
>> Remember, nobody is defending the POSIX pthread APIs here, they're saying
>> that GCD makes Fibers less relevant...
>
> GCD makes Fibers less relevant so long as you are willing to lock your code
> to the MacRuby platform. ;-) But I think
Woah there, cowboy! No need to pull out the "patches welcome" gun, just
sharing a use case from the field. I use Ruby 1.9 now, I hope to someday
switch to MacRuby. It'd be a shame if the implementation of fibers didn't take
into account the situations in which they might be used.
You're, o
On Aug 13, 2010, at 2:01 PM, easco wrote:
> On Aug 13, 2010, at 03:46 PM, easco wrote:
>
>> Unfortunately you are going to have to have someone who has the requisite
>> experience. Since the OS doesn't provide the primitives I thought it might,
>> that person is going to have to understand the
On Aug 13, 2010, at 03:46 PM, easco wrote:Unfortunately you are going to have to have someone who has the requisite experience. Since the OS doesn't provide the primitives I thought it might, that person is going to have to understand the Intel 64-bit ABI, (evidently) DWARF exception handling, Mac
On Aug 13, 2010, at 03:34 PM, "Jordan K. Hubbard" wrote:Remember, nobody is defending the POSIX pthread APIs here, they're saying that GCD makes Fibers less relevant...GCD makes Fibers less relevant so long as you are willing to lock your code to the MacRuby platform. ;-) But I think we've all ag
On Aug 13, 2010, at 12:55 PM, Logan Bowers wrote:
> The state-of-the-art for handling highly concurrent loads is to use an
> event-driven I/O framework. Evented I/O is difficult for the same reasons
> using a GCD queue is difficult, the application and all dependencies have to
> be designed f
I said:>> (i.e. Mac OS X doesn't really have any built-in support for cooperatively scheduled multitasking... outside of >> deprecated technologies like the Carbon Thread Manager and makecontext/swapcontext). Dr. Prabhakar said:Actually, I'm confused by that statement. My understanding is that coop
Unless there's a big piece of GCD I'm missing, it does not serve as a
replacement for Fibers. Enqueuing jobs for execution within a thread pool and
having the system intelligently manage the pool is great. But fibers are
unique in their ability to pause execution at any point.
That is, if I
Hi Logan,
On Aug 13, 2010, at 10:49 AM, Logan Bowers wrote:
> To your point Ernie, yes fibers can be almost perfectly emulated using
> threads. A good, native fiber implementation, however typically uses
> significantly less memory/fiber and context switches are significantly faster
> vs a thr
The use case for me is somewhat more Easco is somewhat more practical. Most
servers on the Internet use a thread-per-request model, which is good for
concurrent workloads up to a few hundred concurrent requests. Yes,
technically you can allocate more threads on a modern system, but rarely ha
I'm with Easco in that I'm patiently waiting for the day Fibers are supported
(or when I have time to contribute) and am happy waiting as long as the
duration is bounded. E.g. If I were waiting for fork(), it sounds like I'd be
here awhile.
To your point Ernie, yes fibers can be almost perfect
Thanks for the example easco.
While perhaps academic, it reminds me of rails ActiveRecord scopes ... which
are not so academic (and working on a finite set of data of course, but there
are similarities).
Ernie is correct: a GCD setup could mimic exactly what one wants to do in this
case ...
Hi Easco,
On Aug 13, 2010, at 8:15 AM, easco wrote:
> Instead I was curious to know if there was "a plan" for implementing Fibers
> and if so, I was curious to know what operating system technology they would
> be built on. It appears that the problem has not been looked at, in-depth,
> yet an
On Aug 12, 2010, at 03:33 PM, macr...@djc.net wrote:While I am certain everyone would agree that 100% compatibility should be the
goal, I am not convinced how "critical" this addition is:
in particular, how difficult is it to do a quick code change?
Unlike basic data types, there are quite a few r
+1 for implementing Fibers in MacRuby.
Rob
http://robgleeson.github.comWebsite
http://github.com/robgleeson GitHub
r...@flowof.infoE-Mail
On 12 Aug 2010, at 21:33, macr...@djc.net wrote:
>
> I agree (I don't see a performance issue, rather, a compatib
I agree (I don't see a performance issue, rather, a compatibility issue)
While I am certain everyone would agree that 100% compatibility should be the
goal, I am not convinced how "critical" this addition is:
in particular, how difficult is it to do a quick code change?
Unlike basic data types
On Aug 11, 2010, at 3:23 PM, easco wrote:
> My concern for the feature is focused not so much on the performance impact
> of using it, as it focuses on the fact that Fibers have been added to the
> 1.9.x language. They appear to be an important part of the External
> Enumerators feature and th
On Aug 11, 2010, at 3:23 PM, easco wrote:
>> Because of the way MacRuby is implemented, fibers would need to unwind the
>> stack most of the time you switch continuations, which has poor runtime
>> performance. We will eventually implement continuations which can serve to
>> implement fibers at
Because of the way MacRuby is implemented, fibers would need to unwind the stack most of the time you switch continuations, which has poor runtime performance. We will eventually implement continuations which can serve to implement fibers at some point (which is what MRI does I believe), but I woul
Hi Logan,
On Aug 11, 2010, at 2:03 PM, Logan Bowers wrote:
> That's a bummer; it sounds like Fibers will never really be useful on the
> MacRuby platform then? :(
They could definitely be useful once they are implemented. But I'm not sure
there would be a case where using them would be prefer
That's a bummer; it sounds like Fibers will never really be useful on the
MacRuby platform then? :(
Out of curiosity, is there a limiting factor in the runtime that prevents the
use of, e.g., makecontext/setcontext or related call?
Logan Bowers
On Aug 11, 2010, at 1:56 PM, Laurent Sansonett
Hi Scott,
Because of the way MacRuby is implemented, fibers would need to unwind the
stack most of the time you switch continuations, which has poor runtime
performance. We will eventually implement continuations which can serve to
implement fibers at some point (which is what MRI does I believ
Sure,
I recommend you look at http://www.stackless.com/ (a fiber-supporting
implementation of Python), and NeverBlock
(http://www.espace.com.eg/neverblock/).
Stackless Python I believe is used extensively on the EVE Online MMO runtime as
fibers/coroutines make for very natural use of the ac
The em-synchrony project wraps a bunch of EventMachine code in fibers:
http://github.com/igrigorik/em-synchrony
I know the author was looking at MacRuby and trying to figure out if fibers
worked just the other day.
dan
On 2010-08-11, at 1:19 PM, Matt Massicotte wrote:
> Could you share some
Could you share some, or maybe provide a link? I'm interested in the topic,
but unfamiliar with any specific use-cases.
Matt
On Aug 11, 2010, at 10:15 AM, Logan Bowers wrote:
> +1 for fibers. There is a class of problems made much simpler and/or possible
> with fibers that are not viable w/th
+1 for fibers. There is a class of problems made much simpler and/or possible
with fibers that are not viable w/threads.
Would love to see this make its way into MacRuby.
Sent from my iPhone
On Aug 11, 2010, at 6:06 AM, Scott Thompson wrote:
>
> On Aug 11, 2010, at 7:23 AM, Louis-Philippe
On Aug 11, 2010, at 7:23 AM, Louis-Philippe wrote:
> Hi Scott,
>
> If you haven't done so already, you might want to have a look at:
> http://www.macruby.org/documentation/gcd.html
>
> it speaks of MacRuby integrating Apple's latest multi-threading strategy:
> Grand Central Dispatch.
Grand Ce
Hi Scott,
On Aug 11, 2010, at 5:23 AM, Louis-Philippe wrote:
> Hi Scott,
>
> If you haven't done so already, you might want to have a look at:
> http://www.macruby.org/documentation/gcd.html
>
> it speaks of MacRuby integrating Apple's latest multi-threading strategy:
> Grand Central Dispatch.
Hi Scott,
If you haven't done so already, you might want to have a look at:
http://www.macruby.org/documentation/gcd.html
it speaks of MacRuby integrating Apple's latest multi-threading strategy:
Grand Central Dispatch.
2010/8/10 Scott Thompson
> I recently had a discussion on a separate list
I recently had a discussion on a separate list about Coroutines and Cooperative
Multitasking on Mac OS X. The general result of that discussion was that the
"best" solutions were to either rely on the (deprecated) Carbon Thread Manager,
use a more complex scheme involving pthreads and semaphore
31 matches
Mail list logo
