etch-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Holger Grandy <>
Subject RE: Etch C Binding Implementation (Compiler + Runtime)
Date Thu, 14 Jan 2010 07:30:26 GMT

Hello James, Youngjin,
hello *,

thank you for your replies.

Most important for us is the question regarding next steps. How can we share
our stuff with the community? Is there a special process / requirements to
get involved into the Etch project? How can we make our source code

Scott, are you the right to answer this question?

James, it would be nice if you could go more into detail regarding the
significant challenges which you mentioned. Of course we read the notes
supplied with the c binding and worked on some of those, too.

To go more into detail on our work: 

- we added a first compiler implementation using velocity 
  (like the existing one for Java). 
  The generated source is inspired by the example source code 
  for the "perf" application (but of course supporting
  all etch features, and not only the ones present in "perf")
- ported the source to Linux / Unix (required some refactorings due
  to compiler differences and some operating system specific code)
- we analyzed the code using a thread analyzer and removed some race
  conditions and deadlocks
- we removed the hashtable based memory allocation code (due to   
  multithreading issues) and used a runtime heap checking library instead 
- removed some memory leaks
- startup code for client and server is refactored
- added a configuration mechanism (either using property files or 
  direct calls)
- logging code was refactored to support different appenders 
  (customizable using above mechanism)
- re-wrote the mutex & condition variables implementation
- Unicode conversion code was refactored to be operatig system independent
  (using apr-iconv)
- refactored the test suite and added some tests
- refactored global variable initialisation and lifecycle management
- refactoring of some namings in the runtime code
- added support for custom exceptions
- serializers for some types, e.g. list, set and map were refactored 
  (they now work exactly as in the Java binding -> all are sent as Object[])
- structured the headers and c files, removed some unused ones
- some general bugfixing and cleanup for runtime code

Looking forward to your answer,

Holger Grandy
Michael Fitzner

Youngjin Park (youngjpa) wrote:
> Hi James,
> I also like to get some assistance after I look into the current codes.
> I have a plan to spend time for C-binding.
> Hi Michael and Holder,
> It is good news. I hope that we can split some of works together for
> C-binding. If you can check in yours soon, I can also start developing
> on the top of the check-in.
> Thanks
> Youngjin
> -----Original Message-----
> From: James deCocq [] 
> Sent: Monday, January 11, 2010 8:49 PM
> To:
> Cc:
> Subject: RE: Etch C Binding Implementation (Compiler + Runtime)
> Hello Michael and Holder,
> As the author of the original C code, I could perhaps be of some
> assistance. In particular, there were a few significant challenges to be
> resolved, perhaps you identified these and did so. 
> James deCocq
>> From:
>> To:
>> CC:
>> Date: Mon, 11 Jan 2010 18:45:28 +0100
>> Subject: Etch C Binding Implementation (Compiler + Runtime)
>> Hi everybody, 
>> we evaluated the Etch SDK several months ago and we think that it is a
> quite good RPC mechanism for our specific needs. Since we need a fully
> functional C binding, we checked out the source. We could not yet
> participate in the community in the last months, but for us this was no
> reason not to look into the source code. So we started implementing the
> C binding. 
>> At the moment we have implemented a functional C Compiler for the Etch
> IDL and worked a lot on bugfixing and finalising the C Runtime Code for
> Etch. RPC calls with nearly all of the Etch features (both in client and
> server direction) are working with fully generated code from the
> Compiler. Some stuff (like e.g. @Authorize) is not yet done, but all
> core features work. 
>> Current state is early beta in our opinion, our Compiler-generated C
> code works for our IDL test suite and the existing Etch runtime test
> suite is running, too. 
>> We did a refactoring of the existing C runtime source code of Etch. We
> did not change the basic architecture, but structurized and cleaned the
> source and enhanced/re-implemented some features, like source for
> startup and configuration, for logging, parts of the threading source,
> for the test suites and some others. 
>> We also did some bugfixing, e.g. related to multi threading race
> conditions and some others.
>> We ported the source code to Unix based systems.
>> Our intention is definitely to participate in the Etch community. We
> want to get in contact and hope that this will be of good use for the
> Etch community and that our efforts will find their way into the Etch
> codebase. It is possible for us to submit our source code back to the
> community, but the timeframe for this is not yet clear. A discussion
> regarding this topic would be very welcome. 
>> We would of course be very happy if our efforts would bring the whole
> project one step further. 
>> Sincerely,
>> Michael Fitzner ( and
>> Holger Grandy (
>> BMW Car IT GmbH
> _________________________________________________________________
> Hotmail: Powerful Free email with security by Microsoft.

View this message in context:
Sent from the etch-dev mailing list archive at

View raw message