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 Henry:
Actually, I haven't learned to use the debugger. I have lots of tracing
messages "put" and when I get a hang I add a raise statement following the last
message generated and rerun to get a traceback. Then I add lots of put messages
to the high level method from the TB to track down th
Alright!
Thanks for all the help. I was able to track down the problem and have some
changes for marshal.c that I need to get back to the repository. There were
some assumptions about the sizes of types that were broken by going to 64-bit .
I don't know the procedures on this project. Do I n
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
17 matches
Mail list logo
