Re: JCSP, CSP Networking, and other some other points

[Adam Sampson <A.T.Sampson@xxxxxxxxxx>]

"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
  synchronisation.

- While you may not *need* to use CSP techniques to implement a
  networking library, it certainly makes it a lot easier... ;)

Thanks,

-- 
Adam Sampson                                         <http://offog.org/>