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

["Chalmers, Kevin" <K.Chalmers@xxxxxxxxxxxx>]

> Something that's come up a few times recently is support for generics -
> -
> i.e. allow Channel<sometype>.

Pretty much my first thought really.  We've talked about it for a couple of years at least.

> 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 was taking a look at the FFI, and thought the best bet for occam would be to write the necessary functions in C and then build the architecture in occam.  But maybe pure CCSP is better?

> > 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:

Me too, but in some ways offering a reference C/C++ implementation could be useful as a starting point for some.  I would agree that really we want to have each framework developer implementing their own version, and hopefully have a protocol we can adhere to.  So your comments are noted.

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

Oh yes :)

Kevin Chalmers,
Lecturer,
School of Computing,
Edinburgh Napier University,
Merchiston Campus,
Edinburgh, EH10 5DT

t: +44 (0)131 455 2484



> -----Original Message-----
> From: Mailing_List_Robot [mailto:sympa@xxxxxxxxxx] On Behalf Of Adam
> Sampson
> Sent: 24 February 2009 11:27
> To: java-threads@xxxxxxxxxx; occam-com@xxxxxxxxxx
> Subject: 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
>   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/>
> 


Napier University is the best modern university in Scotland* and number one in Scotland for graduate employability**
(*Guardian University Guide 2009)
(**HESA 2008)

This message is intended for the addressee(s) only and should not be read, copied or disclosed to anyone else out-with the University without the permission of the sender.
It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects. Napier University does not accept liability for any loss or damage which may result from this email or any attachment, or for errors or omissions arising after it was sent. Email is not a secure medium. Email entering the University's system is subject to routine monitoring and filtering by the University.
Napier University is a registered Scottish charity. Registration number SC018373