Piotr Szturmaj Wrote:
> Reactor is event handling pattern, when client specify event handlers
> like onRecv() and just wait for the events - these are delivered as soon
> as they arrive. Proactor on the other side requires that client issue
> each asynchronous operation manually - there will be
Kagamin wrote:
Piotr Szturmaj Wrote:
Kagamin wrote:
eris Wrote:
Windows uses a "proactor" model instead of reactor, so it schedules I/O first
and
then waits for an IO completion flag. I've modified my reactor so that it
presents
a reactor facade even on Windows systems.
Huh? What does it
Piotr Szturmaj Wrote:
> Kagamin wrote:
> > eris Wrote:
> >
> >> Windows uses a "proactor" model instead of reactor, so it schedules I/O
> >> first and
> >> then waits for an IO completion flag. I've modified my reactor so that it
> >> presents
> >> a reactor facade even on Windows systems.
> >
>
Kagamin wrote:
eris Wrote:
Windows uses a "proactor" model instead of reactor, so it schedules I/O first
and
then waits for an IO completion flag. I've modified my reactor so that it
presents
a reactor facade even on Windows systems.
Huh? What does it change? IO is done pretty much the same
eris Wrote:
> Windows uses a "proactor" model instead of reactor, so it schedules I/O first
> and
> then waits for an IO completion flag. I've modified my reactor so that it
> presents
> a reactor facade even on Windows systems.
Huh? What does it change? IO is done pretty much the same on all s
eris Wrote:
> My library uses a straight-forward reactor approach to handle incoming events
> (IO,
> timer etc). The library is structured as one-thread-per-core and as many
> co-routines (fibers) per thread as memory will allow. The threads communicate
> with each other via lock-free single-w
eris Wrote:
> My library uses a straight-forward reactor approach to handle incoming events
> (IO,
> timer etc). The library is structured as one-thread-per-core and as many
> co-routines (fibers) per thread as memory will allow. The threads communicate
> with each other via lock-free single-w
My library uses a straight-forward reactor approach to handle incoming events
(IO,
timer etc). The library is structured as one-thread-per-core and as many
co-routines (fibers) per thread as memory will allow. The threads communicate
with each other via lock-free single-writer, single-reader FI
Piotr Szturmaj Wrote:
> eris wrote:
> > I used the Tango Fibers implementation (thanks Sean Kelly I believe) and
> > various
> > reactor libraries to implement the actor engine.
>
> I'm working on something similar, e.g. event-driven programming using
> fibers. I need it for my upcoming network
eris wrote:
I used the Tango Fibers implementation (thanks Sean Kelly I believe) and various
reactor libraries to implement the actor engine.
I'm working on something similar, e.g. event-driven programming using
fibers. I need it for my upcoming network library.
But I don't use queue for eac
Andrei wrote:
> Or early by nine!
Ah, yes. Ahem. That's what I meant. I typo'd it. That should read 'for
GSOC2012'.
On 7/7/11 1:47 PM, David Nadlinger wrote:
On 7/7/11 10:50 PM, eris wrote:
Is it too late?
Unfortunately, yes, by about three months:
http://www.google-melange.com/gsoc/events/google/gsoc2011
David
Or early by nine!
Andrei
Sorry for the hasty overview, I was trying to squeeze my request in under the
wire
(and failed).
My previous system (Dendrite) was a D1/Tango implementation of flow-based
programming environment similar to the BBC Kamaelia/Axon system implemented in
Python. It was moderately challenging and fun,
On 7/7/11 11:47 PM, dsimcha wrote:
== Quote from eris (jvbur...@gmail.com)'s article
Walter et al...
I'm interested in finishing my proof-of-concept multi-core actor/flow-based
programming system and I'd like to do it for D2. I've already implemented a
.9 version in D1 and would like to leverag
== Quote from eris (jvbur...@gmail.com)'s article
> Walter et al...
> I'm interested in finishing my proof-of-concept multi-core actor/flow-based
> programming system and I'd like to do it for D2. I've already implemented a
> .9 version in D1 and would like to leverage the additional features and
> Unfortunately, yes, by about three months:
Damn their eyes.
I'll have to do it anyway just for the fun of it.
:-)
On 7/7/11 10:50 PM, eris wrote:
Is it too late?
Unfortunately, yes, by about three months:
http://www.google-melange.com/gsoc/events/google/gsoc2011
David
Walter et al...
I'm interested in finishing my proof-of-concept multi-core actor/flow-based
programming system and I'd like to do it for D2. I've already implemented a
.9 version in D1 and would like to leverage the additional features and
concurrency system in D2.
I'm currently tweaking it for
18 matches
Mail list logo
