[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: JCSP, CSP Networking, and other some other points
" I have had a couple of emails recently asking about progress with JCSP and
with one thing or another we haven't had much time to work on updating the
core JCSP package.."
DON'T FIX IT IF IS NOT BROKEN. First of all.
From: Mailing_List_Robot [mailto:sympa@xxxxxxxxxx] On Behalf Of Chalmers,
Sent: Tuesday, February 24, 2009 4:04 AM
To: java-threads@xxxxxxxxxx; occam-com@xxxxxxxxxx
Subject: JCSP, CSP Networking, and other some other points
This email is going to cover a few different points so bear with me a little
First of all JCSP. I have had a couple of emails recently asking about
progress with JCSP and with one thing or another we haven't had much time to
work on updating the core JCSP package. We have discussed possibilities of
taking JCSP to a Java 1.5/6 version, and utilising various parts of the Java
API to simplify / increase performance, but I don't think any concrete
decisions were made. So my first question is really about where we should
be taking the core JCSP package? What sort of functionality are people
looking for that we don't yet support? I am, finally, going to try and put
various JCSP versions / packages up on the repository, including an updated
JCSP Micro Edition and Jon's JCSP Robot Edition. Possibly Groovy, but
that's a discussion point I feel, as it is not really Java as such.
Secondly, and probably most important from my point of view, is CSP
Networking (for want of a better term). As some of you may know, I have
been working on a generalised protocol and architecture for JCSP, which we
can re-implement on the various CSP platforms/frameworks (occam, C++CSP,
PyCSP, etc.), and thereby gain some form of inter-framework communication.
We are still very much in an early stage, so this is sort of general call
out to interested parties who would like to either contribute some insight,
or, even better, help take things forward. I am currently working with John
Markus in Tromso (when I can) to try and get PyCSP and JCSP to interact. So
far I have JCSP sending strings to Python, and Python acknowledging and
sending back a reply, so we are making some progress. 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. I am
hoping to start a project with this, so as time goes on we can set up the
various resources that we need.
Related to this request is a question on a C/C++ reference library for the
protocol and architecture. 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. To simplify the description of the architecture a little, essentially
there are a series of queues (infinitely buffered channels) which receive
messages for incoming network channels, and TX/RX processes to handle
network comms. When it comes down to it, there is nothing that essentially
requires CSP semantics within the architecture (there is no synchronisation
between the TX/RX processes and the networked channels as the channels are
infinitely buffered), and any shared state can happily be protected within a
standard critical region. So currently I am considering two different
1) Use C++CSP to develop the library, which requires C++CSP and Boost.
2) Use Intel Thread Building Blocks. Only requires one library.
The last time I talked to Neil, he was unsure if C++CSP was 100% Windows
compatible, and also I would have to strip out the existing C++CSP
Networking functionality, meaning it wouldn't be an exact version. TBB I'm
not as familiar with however, so if anyone knows any problems with the
library let me know. If you have any insights into either it could be
School of Computing,
Edinburgh Napier University,
Edinburgh, EH10 5DT
t: +44 (0)131 455 2484
Napier University is the best modern university in Scotland* and number one
in Scotland for graduate employability**
(*Guardian University Guide 2009)
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