[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: JCSP, CSP Networking, and other some other points
"Chalmers, Kevin" <K.Chalmers@xxxxxxxxxxxx> writes:
> So my first question is really about where we should be taking the
> core JCSP package?
Something that's come up a few times recently is support for generics --
i.e. allow Channel<sometype>.
> At a quick count, we have seven frameworks probably looking at having
> some network functionality (JCSP, PyCSP, occam, Transterpreter,
> C++CSP, Haskell CSP, CSO (Scala)), and it would be pretty good if we
> could get an Erlang version as well.
When you say "occam" here, it's actually CCSP -- you can write programs
in other languages on top of it too (we've written quite a lot in C,
including bits of pony, the existing networking system, and I've
experimented with a Python implementation using CCSP lightweight
threads). We've been working on merging the Transterpreter into the KRoC
tree recently, so it's now much easier to share modules and FFI code
between the two.
> I am currently thinking about the best method to go about having a
> standard native library which each CSP framework can essentially hook
> into, thus reducing the overall maintenance / development work.
I've got a few worries about this:
- While you don't then have to rewrite the networking library for each
implementation, you do have to maintain bindings for your native
library in all the languages you want to support, which can be nearly
as much work. In addition, the bulk of the existing pony C code is
support for marshalling the various occam-pi data types into a
portable format; that sort of language-specific code is still going to
need to exist.
- For bytecode-based languages like Java and Python, this means the
concurrency library would no longer be "pure" -- it'd depend on having
a native library built for each platform, which makes packaging and
testing it harder.
- Careful design will be necessary to take advantage of the more
efficient lightweight threading systems provided by CCSP, C++CSP,
Haskell and Erlang. JMB and I got a significant speedup from avoiding
native threads in the occam-pi networking work we did last year; in
order to avoid crippling the library's performance, you'd need to
expose enough of the internals of the library that a lightweight IO
scheduler could be used, and avoid heavyweight native-threads
- While you may not *need* to use CSP techniques to implement a
networking library, it certainly makes it a lot easier... ;)
Adam Sampson <http://offog.org/>