[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Good. JCSP as software product is really solid (I am talking about RC 1.0
that I was using in commercial application).

By the way, why CSP community is silent when it regards programming
multicore processors? There is a lot of nonsense being published recently
regarding this topic, various "thread and parallel" amateurs trying to find
"silver bullets" that in most cases look like "philosophical stone". Even
Wall Street Journal and New York Times write how hard is programming
multicore processors.

In the meantime, CSP community is sitting in Ivory Tower. Isn't CSP, JCSP
and such good tools for multicore, and will multicore be the next
missing/ignored opportunity for CSP community?

A.L. 

-----Original Message-----
From: Mailing_List_Robot [mailto:sympa@xxxxxxxxxx] On Behalf Of Chalmers,
Kevin
Sent: Tuesday, February 24, 2009 7:26 AM
To: Andrzej Lewandowski; java-threads@xxxxxxxxxx; occam-com@xxxxxxxxxx
Subject: RE: JCSP, CSP Networking, and other some other points

Nothing within the core underlying functionality will change (unless Peter
adds anything).  We are really talking externally.  For example, typed
channels shouldn't be a problem and would utilise the existing channels
underneath.  Library wise, we can consider support for Swing (AWT is old),
etc.  Don't think of this as a modification exercise, more an extension.

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

t: +44 (0)131 455 2484



> -----Original Message-----
> From: Andrzej Lewandowski [mailto:lewando@xxxxxxxxxxxxx]
> Sent: 24 February 2009 12:38
> To: Chalmers, Kevin; java-threads@xxxxxxxxxx; occam-com@xxxxxxxxxx
> Subject: 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.
> 
> A.L.
> 
> -----Original Message-----
> From: Mailing_List_Robot [mailto:sympa@xxxxxxxxxx] On Behalf Of
> Chalmers,
> Kevin
> Sent: Tuesday, February 24, 2009 4:04 AM
> To: java-threads@xxxxxxxxxx; occam-com@xxxxxxxxxx
> Subject: JCSP, CSP Networking, and other some other points
> 
> All,
> 
> 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
> approaches:
> 
> 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
> useful also.
> 
> Cheers,
> 
> Kevin
> 
> Kevin Chalmers,
> Lecturer,
> School of Computing,
> Edinburgh Napier University,
> Merchiston Campus,
> 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)
> (**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
> 
> 
> 


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