On 7/10/07, skaller <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-07-10 at 12:59 -0400, Sandro Magi wrote:
> > On 7/10/07, skaller <[EMAIL PROTECTED]> wrote:
>
> > As long as you can continue useful computation while blocking, and you
> > can do so safely, then you have a good concurrency model.
>
> On blocking: it's the other way around. The current fibre
> executes UNTIL it blocks (or dies).
So there are continuations being used to block and resume computation.
The only difference seems exactly what you pointed out: promises are a
type of reified continuation that the client can actually pass around
until it chooses to block (by calling 'when'), instead of when they
invoke the operation.
> Blocking is the only way to hand control over
> to another fibre. If a fibre deadlocks, it is removed,
> so fibres simply cannot deadlock.
How do you detect deadlocks? Is the procedure you describe below where
the thread is GC'd?
> > I'm not sure
> > I see wow your approach is more efficient or safer than futures+event
> > loops (doesn't seem less efficient either).
>
> It isn't more efficient or safer because the model DOES use
> futures and event loops!
> [...]
> We have two standard servers: demux (for sockets etc)
> and a timer thread.
Sounds interesting. I'll have to think about it a bit more, as I think
it almost exactly reverses my ingrained block/unblock semantics.
> At this point we do not have servers for:
>
> (a) SCARY ... Unix signals :)
I doubt very much they're worth it, except perhaps one or two of them.
> (b) Interprocess Communication
> (c) other stuff, eg Windowing systems ..
Certainly useful.
> > So what you want is functional reactive programming (FRP), which
> > provides such dynamic circuit switching. You should definitely look
> > into it if you haven't already.
>
> I have, but my stuff was in the works long before FRP was invented,
> so they're just re-inventing my wheel .. :)
Hm, first FRP papers were mid-1990's I think. Still, the dynamic
switching is something you don't have yet. ;-)
> > What you describe, basic primitive
> > values and combinators to wire circuits, is essentially a dataflow
> > graph as built using FRP signals/events + combinators. However, there
> > are concurrency dangers in executing this graph naively. See FrTime
> > [1] for details. These are the exact same concurrency problems that
> > event loops in E solve.
>
> With synchronous threads there are no dangers, other than the usual
> problem of making a mess of your code :) I've done that.. it's quite
> easy to forget to plug a channel in, so that when a fibre reads it
> it suicides .. that may be unexpected but it is well defined
> behaviour.
Still trying to grasp this. How do you forget to "plug in" a channel?
> With asynchronous threads (pre-emptive threads) there are
> definitely issues .. but whilst Felix DOES provide the programmer
> with pre-emptive threading as well as the synchronous threading,
> the emphasis is on not needing this stuff: the async I/O system
> interfaces to the sync I/O system seamlessly.
>
> Still, once you add the async I/O into the picture lockups
> are possible -- and this is entirely unavoidable when you're
> reliant on external event sources.
How does the async I/O introduce lockups? Do multiple kernel threads
execute the queue of fthreads simultaneously?
> > A 'vat' is pretty much the 'process' abstraction, which I think you'd
> > agree is fairly important and well-founded.
>
> No, it is only half a system, so it is meaningless. It is only
> when you specify a way processes communicate that you have an
> actual model.
E is based on a pure object model, which means messages are the
primary communication mechanism. Vats+message passing seems isomorphic
to processes+channels.
> > The vat is the unit of
> > concurrency, failure, persistence and resource control. E also
> > enforces the property that each 'process' has a single event loop by
> > which all computation is driven, and this+persistence turns a process
> > into an E vat.
>
> Right. But I still don't know what that achieves .. or how it
> is different from Felix.
>
> Every Felix 'pthread' has its own event loop too:
>
> spawn_pthread { .... };
>
> actually spawns a complete new synchronous scheduler with
> its own async queue as well. [And until recently it also
> spawned its own socket and timer server which was a really
> bad idea .. that's fixed now]
>
> This isn't a process because these threads still share memory
> and a single garbage collector. However there are channels
> for them too, pchannels. Which are a mutex locked synchronisation
> primitive.
>
> Major difference here is that pthreads don't get deleted by
> the operating system when they deadlock .. they're usually
> only reaped when the main process terminates.
>
Given the above, it seems the only difference between Felix threads
and Vats are that Vats have distinct memory spaces (like processes),
and because E supports semi-transparent distribution, you can hold a
far reference to an object in Vat B in Vat A. Sending a message to
this object analyzes the message for pass by copy or pass by reference
semantics, and serializes or sends a far reference accordingly.
So Vats encompass a broader semantics than a simple process
(obviously), and distributed functionality that Felix threads do not
(yet?) provide. Also, even asynchronous events do not introduce
deadlocks in E code since Vats are single-threaded; there is a type of
lock which can occur called a datalock [1], which they describe as "a
recursive data definition with no bottom" (so an ill-founded recursive
data dependency).
Sandro
[1] http://www.erights.org/elib/concurrency/event-loop.html
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
