Jonathan S. Shapiro wrote:
> On Wed, Feb 4, 2009 at 7:31 PM, Sam Rushing
> <[email protected]
> <mailto:[email protected]>> wrote:
>
>
> > Things I'd like to have in both languages:
> >
> > lightweight threads
>
> The term "lightweight threads" means very different things to
> different people. We left concurrency out of the BitC language spec
> because nobody knows how to do concurrency "right" yet. What is it
> that you actually want?
>
I want to do something like Erlang. I've built several systems like it
using different forms of Stackless Python.
They run on FreeBSD using kqueue(). As an example, when a call to
accept() would block, I tell kqueue() to let me know when a new
connection comes in, then I put that thread to sleep. When the event
comes in, I schedule the thread. Depending on how you look at it, you
could call it a user-level cooperative threading library.
> > generators
>
> What do you mean by "generators"?
>
Imagine you have a binary tree. You write the simple and obvious
procedure to walk its contents. At each node, you 'yield' with the data
at that node. You create a generator to produce those values one at a time.
Here's one of my tests:
(include "lib/core.scm")
(define (make-int-generator)
(make-generator
(lambda (consumer)
(let loop ((n 0))
(consumer n)
(loop (+ n 1))))))
(let ((g (make-int-generator)))
(define (every-other)
(let ((first (g)))
(cond ((zero? first)
first)
(else
(g)))))
(printn g)
(printn (every-other))
(printn (every-other))
(printn (every-other))
(printn (every-other))
(printn (every-other))
)
Useful for lots of things. One of my favorites is that you can turn
interfaces 'inside out'. For example, you can take a data-driven lexer
(i.e., one that you feed data to one block at a time), and using a
generator make it act like a blocking object that produces tokens...
(i.e., a (next-token) function).
> >
> > ability to dump and load an image
>
> BitC does not have this. While we are looking at building an
> interactive BitC environment, and such an environment certainly needs
> a dump mechanism, BitC is primarily focused on being a static
> compiler. One problem with the interactive approach is that it doesn't
> handle cross compilation very well...
>
Yeah, this is where our goals might diverge. Though like with the other
features, I could probably implement dump/load/marshalling/etc in the
high-level language and *not* in the low-level one.
dump/load is really nice for things like CGI (not that I approve) and
checkpointing.
The ability to marshal up the state of a thread and ship it to another
machine is *wildly* popular with the Stackless Python community. I've
never understood it, it's either really sexy, or people want it for
scalability/redundancy across multiple machines.
-Sam
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
