View previous topic :: View next topic |
Author |
Message |
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Tue Nov 30, 2004 1:44 pm Post subject: Ares updates |
|
|
A new Ares release is available at:
http://home.f4.ca/sean/d/ares.zip
Latest changelog updates:
* Merged in DMD .108 changes
* Added static count() property to Thread
* Added name() property to Thread
* Eliminated [std.hook] and moved the remaining bits into [std.error]
* Added setAssertHandler()
Things are starting to look pretty solid for a basic Ares framework, though the linux side is still sorely neglected.
Last edited by sean on Fri Sep 16, 2005 11:57 am; edited 1 time in total |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Tue Nov 30, 2004 1:48 pm Post subject: Re: Ares updates |
|
|
sean wrote: | * Merged in DMD .108 changes |
Wow! I guess 0.107 was a short-lived release
Thanks for adding the name property! |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Tue Nov 30, 2004 4:52 pm Post subject: Re: Ares updates |
|
|
sean wrote: | Things are starting to look pretty solid for a basic Ares framework, though the linux side is still sorely neglected. |
What needs to be done on the Linux side? |
|
Back to top |
|
|
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Tue Nov 30, 2004 6:43 pm Post subject: |
|
|
Makefiles need to be created. The ones there now are old Phobos versions. Also, the Thread class needs to be finished. I've got a pthreads book at work, but I do most of my coding elsewhere.
Other wishlist items:
* create a pthread header file and add it to ares/std/c/unix
* finish the support files for [std.c.unix.unistd]--I think it needs [std.c.unix.sys.types] and one other file I'm forgetting. IIRC Thomas Kuehn has a complete version of unistd on his website which includes the appropriate definitions, but I I like to follow the C header layout as closely as possible when exposing stuff to D. |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Tue Nov 30, 2004 7:02 pm Post subject: |
|
|
I may be able to help out. I can:
- make a makefile for linux
- see about making the pthread header
- look into the Linux thread class (no promises here: I'm not a guru in linux threads; but it may be possible to work out some ideas).
About the unix packages: is using the "unix" name a good idea for that (trademarked name)? Which unix-clones are guaranteed to support this standard? Would POSIX be a better standard to follow?
Thanks,
John |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Wed Dec 01, 2004 7:19 am Post subject: |
|
|
I don't have a pthreads book. I assumed that I could work from the Linux pthread.h header file. Would that work? Or is it going to be somewhat system specific? |
|
Back to top |
|
|
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Wed Dec 01, 2004 10:32 am Post subject: |
|
|
I think the Linux pthread header will work, and I have a BSD shell account where I can probably track down the header for comparison. I'm going to try and finish the Linux Thread class today, but it would be a great help if you could take care of the makefiles and possibly that pthread header. |
|
Back to top |
|
|
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Wed Dec 01, 2004 11:55 am Post subject: |
|
|
Quick note: the current Ares build is broken. Something weird is going on between the gc code and the thread module. I'll have a fix up today once I figure it out. |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Wed Dec 01, 2004 3:37 pm Post subject: |
|
|
Hello Sean,
Okay, I've started the pthreads module. I was surprised to see how big it is. It includes a couple of other headers and structures. I'm about 2/3's done it ATM. After I finish it, perhaps you can clean it up to make sure it's what you need.
I'll also start the makefile today.
Talk to you later,
John |
|
Back to top |
|
|
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Wed Dec 01, 2004 6:19 pm Post subject: |
|
|
Thanks!
Okay a new version of ares is up on my website. This version is bug-free (AFAIK), but I'm not entirely satisfied with some of the fixes I made. There were two problems.
First, all threads are registered in an associative array and I was retrieving the thread count by returning allThreads.length. The problem with this turned out to be that when a new thread is mapped, the garbage collector executes some code which checks the thread count. For some crazy reason, the length property of assoc. arrays doesn't seem to be stored statically because attempting to read it here was crashing the application with what looked like an access violation. I'd like to verify with Walter if there are any guarantees on assoc. array implementation to see if this is a bug. The fix was to add a static variable that handled the thread count separate from the assoc. array.
Second, the 'mark' function in the garbage collector apparently hates being called from within a foreach block--it crashes the app. I'm not sure what's causing this and am going to ask Walter about it as well. The fix was to call Thread.getAll and use a for loop on the returned array. Not a big deal though I'd really prefer to use the static opApply if possible. |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Wed Dec 01, 2004 6:49 pm Post subject: |
|
|
No... thank you! It hadn't really occurred to me what you've been up to all this time. You've done a lot of work and it looks very promising. If I can ease the burden a bit, all the better. It's especially nice to see the compiler dependencies being extracted into their component parts.
sean wrote: | Okay a new version of ares is up on my website. This version is bug-free (AFAIK), but I'm not entirely satisfied with some of the fixes I made. There were two problems.
First, all threads are registered in an associative array and I was retrieving the thread count by returning allThreads.length. The problem with this turned out to be that when a new thread is mapped, the garbage collector executes some code which checks the thread count. For some crazy reason, the length property of assoc. arrays doesn't seem to be stored statically because attempting to read it here was crashing the application with what looked like an access violation. I'd like to verify with Walter if there are any guarantees on assoc. array implementation to see if this is a bug. The fix was to add a static variable that handled the thread count separate from the assoc. array.
Second, the 'mark' function in the garbage collector apparently hates being called from within a foreach block--it crashes the app. I'm not sure what's causing this and am going to ask Walter about it as well. The fix was to call Thread.getAll and use a for loop on the returned array. Not a big deal though I'd really prefer to use the static opApply if possible. |
Argh! Sounds very buggy to me... I hope you can get to the bottom of it.
One issue I need to ask about:
I have a couple of version statements per pthreads.h that go something like this:
version(USE_UNIX98)
{
..
}
version(USE_XOPEN2K)
{
..
}
These are interspersed through pthreads to add extra features if these versions are active. But sometimes pthreads has ifdefs that need both versions active for features to be present.
How do you do an equivalent of
version(USE_UNIX98 || USE_XOPEN2K)
{
..
}
in D. Or should I even bother worrying about all those version statements?
Later,
John |
|
Back to top |
|
|
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Wed Dec 01, 2004 8:11 pm Post subject: |
|
|
You can't :-/ Walter wanted to keep version statements simple so they don't support expression logic. I've been assuming that this level of configuration would probably happen in the makefile, which would pass a whole bunch of version flags to the module. But in this case I wouldn't worry about it. What I'm really interested in for these headers is stuff that's required by the applicable standard, not platform-specific extensions.
BTW, there's yet another ares release up (no changelog changes) that tightens the screws in a few places. I fixed the first of my problems in the assoc. array runtime code but I've left the workaround in place in the Thread object for now. I'm hoping Walter will get back to me re: the opApply problem though. |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Wed Dec 01, 2004 9:42 pm Post subject: |
|
|
Okay... I figured out a alternative method in the meantime. I realize some of the functions were not necessary to add, but since I had done most of them already, I'll leave it to you to rip them out if you feal like it. Compiling a straight dmd -c pthread.d will skip the versioned ones anyway.
It's about done. There are probably some typos, but it compiles otherwise without error. I haven't yet tested the linkage yet. Should I add some of the signal stuff and semaphores that you use for threads? Or is that packaged separately?
How do you want me to send it to you?
Later,
John |
|
Back to top |
|
|
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Thu Dec 02, 2004 9:54 am Post subject: |
|
|
Yes, signals and semaphores would be quite useful. There is some signal stuff already in the C99 headers I did, but I imagine POSIX at least defines additional signal id's. And semaphores are quite important--they're already being used in the linux version of the Thread class.
You can email the files to me if you'd like. I'll msg you with the address. |
|
Back to top |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Thu Dec 02, 2004 9:56 am Post subject: |
|
|
sean wrote: | Thanks!
Okay a new version of ares is up on my website. This version is bug-free (AFAIK), but I'm not entirely satisfied with some of the fixes I made. There were two problems.
First, all threads are registered in an associative array and I was retrieving the thread count by returning allThreads.length. The problem with this turned out to be that when a new thread is mapped, the garbage collector executes some code which checks the thread count. For some crazy reason, the length property of assoc. arrays doesn't seem to be stored statically because attempting to read it here was crashing the application with what looked like an access violation. I'd like to verify with Walter if there are any guarantees on assoc. array implementation to see if this is a bug. The fix was to add a static variable that handled the thread count separate from the assoc. array.
Second, the 'mark' function in the garbage collector apparently hates being called from within a foreach block--it crashes the app. I'm not sure what's causing this and am going to ask Walter about it as well. The fix was to call Thread.getAll and use a for loop on the returned array. Not a big deal though I'd really prefer to use the static opApply if possible. |
You are welcome to pull the Mango.cache.HashMap into Ares for your purposes Sean. It is thread-safe, non-blocking, and has none of the weirdness associated with the native hash-maps. |
|
Back to top |
|
|
|