On 05/31/2013 01:14 PM, Thad Guidry wrote:
## Design and implement some solution for select / async events
We need a way to efficiently wait on multiple types of events at
once, including port receives, I/O reads, socket accepts, timers.
This has some very complicated requirements to satisfy, as
detailed in the linked issue, and I'm not sure what the right
abstractions are here. This is super important and the biggest
risk to the whole effort. If anybody has opinions about this topic
I would love to hear them.
https://github.com/mozilla/rust/issues/6842
My 2 cents worth nothing :-) and I've replied inside the issue with
the same idea... It seems to be very similar in tone to what Vadim
described for .NET asyncs where you wait for a timeout or all
operations (steps) to complete from an abstract view.
This idea comes out of the Data Architect world that I live in. It's
more along the lines of that basic idea that your pitching which I
call "receivership".
In Pentaho Data Integration, there is a process step called "Block
this step until steps finish". What it does is Block a single step in
an execution flow until a selected step or even multiple steps
somewhere in the chain or process has completed it's execution and
returned a True for it's "execution complete flag" where a launched
listener is waiting and watching.
It's a generic wrapper if you will, for additional next steps to
perform, but those next steps do not get called, do not get any input,
and no variables are passed to them until the child Blocking step has
seen from (there's a listener process launched for each step or steps
choosen to watch) all its parent or parents steps somewhere say that
it's own execution has finished and lets the listener know. I think
the "Block this step until steps finish" just waits for all those
listeners it is watching to say it's OK to proceed with it's own set
of next steps.
--
-Thad
http://www.freebase.com/view/en/thad_guidry
Thad,
I think my lack of knowledge in this domain is hurting my comprehension,
and sadly the JavaDocs are pretty impenetrable on casual observation,
but this does sound similar in effect to an approach based on futures.
Perhaps you could sketch out in the issue a simple Rust-like example of
receivership.
-Brian
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
