www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Porting Doug's concurrent library

reply Mike Swieton <mike swieton.net> writes:
I have started to continue Ben's excellent work in porting Doug Lea's
concurrent library to D, and I'm not sure what approach is best in all cases.

D has a different featureset than Java, so there are issues that must be
considered when porting Java code to D. Here is the basic philosophy I've been
considering for porting the concurrent library:

	* Being faithful to Doug's original Java code is less important than
	  creating a good library.
	* Type safety is good. Lean towards avoiding casts when possible.
	* Minimalism is good. The interface should not be unnecessarily complicated.

To this end, I'm considering the below changes. A couple are going to be a bit
controversial, so I'm curious to see what people think.
	
	* Collection-type classes use templates. It's annoying to have to cast the
		output all the time, and it's simple enough to alias a TFoo!(Object)
		instantiation, so you can have a Java-style class if you want.

	* Use of delegates instead of a Runnable interface. Since both strategies
		allow state to be carried in an object, there's no reason to require a
		Runnable. Requiring the use of a class would be a disadvantage, in fact,
		because of D's lack of inner class support.

	* Some constructs don't need to support primitive types. I'm referring to
		the Channel interface here. The API and the implementation would be
		simpler if the stored objects could be null. Since this is expected to be
		the common case, I think this would be fine. To store a primitive in such
		a container, a small templated class could be made, something like:

			class ObjectBox(T) {
					T var;
				public:
					this(T t) { var = t; }
					T get() { return var; }
			}

		I think that this solution would be acceptable in most cases.

I don't see any way in which these changes would reduce the functionality of
the library, but I'm curious to see what other people think of them. Ben,
guys, what do you think? Is this the way to go?

Mike Swieton
__
But it is vital to remember that information - in the sense of raw data - is
not knowledge; that knowledge is not wisdom; and that wisdom is not foresight.
	- Sir Arthur C Clarke
May 07 2004
next sibling parent "Ben Hinkle" <bhinkle4 juno.com> writes:
"Mike Swieton" <mike swieton.net> wrote in message
news:pan.2004.05.07.17.07.08.515726 swieton.net...
 I have started to continue Ben's excellent work in porting Doug Lea's
 concurrent library to D, and I'm not sure what approach is best in all

 D has a different featureset than Java, so there are issues that must be
 considered when porting Java code to D. Here is the basic philosophy I've

 considering for porting the concurrent library:

 * Being faithful to Doug's original Java code is less important than
   creating a good library.

Agreed - also I started to find Java's "one class per file" a little annoying so I combined things like exceptions and small helper classes into the same files.
 * Type safety is good. Lean towards avoiding casts when possible.
 * Minimalism is good. The interface should not be unnecessarily

 To this end, I'm considering the below changes. A couple are going to be a

 controversial, so I'm curious to see what people think.

 * Collection-type classes use templates. It's annoying to have to cast the
 output all the time, and it's simple enough to alias a TFoo!(Object)
 instantiation, so you can have a Java-style class if you want.

Agreed. Templates gooood. Casting baaaad.
 * Use of delegates instead of a Runnable interface. Since both strategies
 allow state to be carried in an object, there's no reason to require a
 Runnable. Requiring the use of a class would be a disadvantage, in fact,
 because of D's lack of inner class support.

Agreed - though functions should be allowed, too. For example, std.thread allows you to create a thread with a delegate or a function as the "runnable". It is kindof annoying to have the near-duplication of code and fields but I think we just following what thread.d does.
 * Some constructs don't need to support primitive types. I'm referring to
 the Channel interface here. The API and the implementation would be
 simpler if the stored objects could be null. Since this is expected to be
 the common case, I think this would be fine. To store a primitive in such
 a container, a small templated class could be made, something like:

 class ObjectBox(T) {
 T var;
 public:
 this(T t) { var = t; }
 T get() { return var; }
 }

 I think that this solution would be acceptable in most cases.

Agreed. My impression is that the typical use case for a Channel is to have multiple worker threads grabbing the objects coming out of a channel and processing them and that really only works if the channel is homogeneous. Items in the channel are probably bigger than a single primitive. Also if the user wants to have custom structs in the channel they can alway subclass some channel and add an API to put/take their struct. Thanks for helping out!
 I don't see any way in which these changes would reduce the functionality

 the library, but I'm curious to see what other people think of them. Ben,
 guys, what do you think? Is this the way to go?

 Mike Swieton
 __
 But it is vital to remember that information - in the sense of raw data -

 not knowledge; that knowledge is not wisdom; and that wisdom is not

 - Sir Arthur C Clarke

May 07 2004
prev sibling parent reply Mike Swieton <Mike_member pathlink.com> writes:
In article <pan.2004.05.07.17.07.08.515726 swieton.net>, Mike Swieton says...
I have started to continue Ben's excellent work in porting Doug Lea's
concurrent library to D, and I'm not sure what approach is best in all cases.

Well, there was no wailing or gnashing of teeth at this, so here's a tarball of what I've done so far. Feel free to test it and find bugs in it 8-} Feedback of any sort welcome. Human salvation lies in the hands of the creatively maladjusted. - Martin Luther King, Jr.
May 08 2004
next sibling parent reply Ben Hinkle <bhinkle4 juno.com> writes:
I'll submit it to the subversion codebase, assuming that is ok with
you. Would you like to have write access to the repository?

On Sat, 8 May 2004 18:04:24 +0000 (UTC), Mike Swieton
<Mike_member pathlink.com> wrote:

In article <pan.2004.05.07.17.07.08.515726 swieton.net>, Mike Swieton says...
I have started to continue Ben's excellent work in porting Doug Lea's
concurrent library to D, and I'm not sure what approach is best in all cases.

Well, there was no wailing or gnashing of teeth at this, so here's a tarball of what I've done so far. Feel free to test it and find bugs in it 8-} Feedback of any sort welcome. Human salvation lies in the hands of the creatively maladjusted. - Martin Luther King, Jr.

May 08 2004
parent Mike Swieton <mike swieton.net> writes:
On Sat, 08 May 2004 18:07:11 -0400, Ben Hinkle wrote:

 I'll submit it to the subversion codebase, assuming that is ok with
 you. Would you like to have write access to the repository?
 

Perfectly fine. Consider my contributions to be public domain. Write access would be excellent, thank you. Mike Swieton __ I've developed a new philosophy. I only dread one day at a time. - Charlie Brown
May 08 2004
prev sibling next sibling parent "Walter" <newshound digitalmars.com> writes:
Nice! Can you email a copy to Doug Lea?

"Mike Swieton" <Mike_member pathlink.com> wrote in message
news:c7j7f8$1td1$1 digitaldaemon.com...
 In article <pan.2004.05.07.17.07.08.515726 swieton.net>, Mike Swieton

I have started to continue Ben's excellent work in porting Doug Lea's
concurrent library to D, and I'm not sure what approach is best in all


 Well, there was no wailing or gnashing of teeth at this, so here's a

 what I've done so far. Feel free to test it and find bugs in it 8-}

 any sort welcome.

 Human salvation lies in the hands of the creatively maladjusted.
         - Martin Luther King, Jr.

May 25 2004
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
What's a .bz2 file? Can you make it into a .zip file?

"Mike Swieton" <Mike_member pathlink.com> wrote in message
news:c7j7f8$1td1$1 digitaldaemon.com...
 In article <pan.2004.05.07.17.07.08.515726 swieton.net>, Mike Swieton

I have started to continue Ben's excellent work in porting Doug Lea's
concurrent library to D, and I'm not sure what approach is best in all


 Well, there was no wailing or gnashing of teeth at this, so here's a

 what I've done so far. Feel free to test it and find bugs in it 8-}

 any sort welcome.

 Human salvation lies in the hands of the creatively maladjusted.
         - Martin Luther King, Jr.

May 25 2004
parent reply Mike Swieton <mike swieton.net> writes:
On Tue, 25 May 2004 14:39:02 -0700, Walter wrote:

 What's a .bz2 file? Can you make it into a .zip file?
 

Common *nix archive format. Don't use that archive anyway; it's since been moved onto Dsource.org. If you have a Subversion client, you can check it out with a command like: svn co http://svn.dsource.org/svn/projects/concurrent If not, there's a zip up, which will likely be out of date extremely soon (I'm working on it now), at: http://www.csis.gvsu.edu/~swietonm/concurrent.zip And as to your other message, I don't consider this code production quality yet. Announcing it to Doug may be premature. In any case, I haven't done so yet. Unless Ben has? Mike Swieton __ Ah, well, then I suppose I shall have to die beyond my means. - Oscar Wilde, last words
May 25 2004
next sibling parent Ben Hinkle <bhinkle4 juno.com> writes:
Mike Swieton wrote:

 On Tue, 25 May 2004 14:39:02 -0700, Walter wrote:
 
 What's a .bz2 file? Can you make it into a .zip file?
 

Common *nix archive format. Don't use that archive anyway; it's since been moved onto Dsource.org. If you have a Subversion client, you can check it out with a command like: svn co http://svn.dsource.org/svn/projects/concurrent If not, there's a zip up, which will likely be out of date extremely soon (I'm working on it now), at: http://www.csis.gvsu.edu/~swietonm/concurrent.zip And as to your other message, I don't consider this code production quality yet. Announcing it to Doug may be premature. In any case, I haven't done so yet. Unless Ben has?

nope.
 Mike Swieton
 __
 Ah, well, then I suppose I shall have to die beyond my means.
 - Oscar Wilde, last words

May 25 2004
prev sibling parent "Walter" <newshound digitalmars.com> writes:
"Mike Swieton" <mike swieton.net> wrote in message
news:pan.2004.05.25.22.45.55.222228 swieton.net...
 And as to your other message, I don't consider this code production

 yet. Announcing it to Doug may be premature.

Ok.
 In any case, I haven't done so
 yet.

I agree on waiting until it is done. If he'll host a link to it, that will raise the visibility of it (and D) quite a lot. I also see it as a nice demonstration of techniques for translating Java to D, opening the door to other packages being converted.
May 25 2004