FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Ares updates
Goto page 1, 2, 3, 4, 5, 6, 7, 8, 9  Next
 
Post new topic   Reply to topic     Forum Index -> Ares
View previous topic :: View next topic  
Author Message
sean



Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA

PostPosted: Tue Nov 30, 2004 1:44 pm    Post subject: Ares updates Reply with quote

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
View user's profile Send private message
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Tue Nov 30, 2004 1:48 pm    Post subject: Re: Ares updates Reply with quote

sean wrote:
* Merged in DMD .108 changes

Wow! I guess 0.107 was a short-lived release Smile

Thanks for adding the name property!
Back to top
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Tue Nov 30, 2004 4:52 pm    Post subject: Re: Ares updates Reply with quote

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
View user's profile Send private message
sean



Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA

PostPosted: Tue Nov 30, 2004 6:43 pm    Post subject: Reply with quote

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
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Tue Nov 30, 2004 7:02 pm    Post subject: Reply with quote

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
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Wed Dec 01, 2004 7:19 am    Post subject: Reply with quote

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
View user's profile Send private message
sean



Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA

PostPosted: Wed Dec 01, 2004 10:32 am    Post subject: Reply with quote

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
View user's profile Send private message
sean



Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA

PostPosted: Wed Dec 01, 2004 11:55 am    Post subject: Reply with quote

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
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Wed Dec 01, 2004 3:37 pm    Post subject: Reply with quote

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
View user's profile Send private message
sean



Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA

PostPosted: Wed Dec 01, 2004 6:19 pm    Post subject: Reply with quote

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
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Wed Dec 01, 2004 6:49 pm    Post subject: Reply with quote

sean wrote:
Thanks!


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? Sad

Later,

John
Back to top
View user's profile Send private message
sean



Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA

PostPosted: Wed Dec 01, 2004 8:11 pm    Post subject: Reply with quote

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
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Wed Dec 01, 2004 9:42 pm    Post subject: Reply with quote

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
View user's profile Send private message
sean



Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA

PostPosted: Thu Dec 02, 2004 9:54 am    Post subject: Reply with quote

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
View user's profile Send private message
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Thu Dec 02, 2004 9:56 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> Ares All times are GMT - 6 Hours
Goto page 1, 2, 3, 4, 5, 6, 7, 8, 9  Next
Page 1 of 9

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group