Hey Holger, Yes, I would suggest that Scott Comer and/or James Dixson hook you up with the powers that be in order to become beatified as committers. Would it be possible for you to demonstrate the ability to compile and run some of the same example IDL as found in the Java project, at least that for which the C implementation has current support? If so, I am sure that all will be delighted to have your energy, contributions, and indeed direction on this project. I am not currently involved so you certainly have my blessing for whatever that may be worth. Since you want to remove the debug allocator however, will you be able to document the means by which others who might want to work on the project can easily pinpoint leaks, and that those using it in beta execution can pinpoint leaks which were not identified in testing? It is very important to have good feedback on memory leaks on a project like this. As you know there are certainly some improvements which could be made. Perhaps Youngjin Park will choose to field one or more these. Here are some issues I remember at the moment. * The code evolved without a clear object model design up fron unfortunately. It is unduly complex, in that it tries to mimic the java implementation. In retrospect it could be much simpler. If I were starting again from scratch I might either go all the way and use some variation of COM-style objects (COM from scratch), or go the other very simplistic direction and mimic single inheritance entirely with object masks, like some of the code wound up doing. You may indeed have better ideas. As a result, there is a piece of code which requires an "is a" test that has some ugly logic and constructs, unless you changed it. Also, as I am sure you know, the type system, which sort of evolved with necessity, needs a redesign, including support for a simple object type for objects that don't need the overhead. * The java "todo" facility was never implemented in the C version. This was as I recall an afterthought to postpone execution of code which to run inline would result in race condition. I don't recall what functionality is affected by this omission. If I were starting from scratch I might might use an event loop to build in the thread discontinuity which the java "todo" code attempts to retrofit. * The array logic is wanting, for a few reasons. One, the wire protocol design (no array metadata in advance) made it not possible to know what the attributes of an array were until the end of the array was encountered (unless you were to lookahead which is also not practical for obvious reasons). Two, since we could not of course ask something primitive what its type is in C, there is currently no facility for streaming of bytes -- everything gets translated into an object prior to serialization or on deserialization. This could prove problematic for large arrays since their memory requirements could be fifty or so times that of a byte stream. * I think there may have been one or three potential race conditions due to non-atomicity. Best of luck, James deCocq
> Date: Wed, 13 Jan 2010 23:30:26 -0800 > From: [email protected] > To: [email protected] > Subject: RE: Etch C Binding Implementation (Compiler + Runtime) > > > 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 > available? > > 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 [mailto:[email protected]] > > Sent: Monday, January 11, 2010 8:49 PM > > To: [email protected] > > Cc: [email protected] > > 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: [email protected] > >> To: [email protected] > >> CC: [email protected] > >> 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 ([email protected]) and > >> Holger Grandy ([email protected]) > >> > >> BMW Car IT GmbH > >> > > > > _________________________________________________________________ > > Hotmail: Powerful Free email with security by Microsoft. > > http://clk.atdmt.com/GBL/go/196390710/direct/01/ > > > > > > -- > View this message in context: > http://n2.nabble.com/Etch-C-Binding-Implementation-Compiler-Runtime-tp4287753p4391168.html > Sent from the etch-dev mailing list archive at Nabble.com. _________________________________________________________________ Hotmail: Free, trusted and rich email service. http://clk.atdmt.com/GBL/go/196390708/direct/01/
