Hi, I left a comment on your blog but maybe this is the better place to ask. Would it be possible to add a yield_thread function to the threaDS library. I'd like to implement mutexes in a reasonably efficient way.
Also, what license does threaDS use? I'm hoping for GPL compatibility since that's what I'm stuck with at the moment.
Hi, i'm currently not at home so maybe you can wait 2 day?
For the 14/04 in the mourning i'll be at home and we can talk about my library, your project and the licence.
It's ok for you? I'm sorry, but i don't have a good connection here, see you later.
Sure, no problem. Take your time!
I'm looking at some licences: GPL, CC, WTFPL and i think i'll release ThreaDS under the GPL, but i'm going to take the night to think about it.
What about the yield_thread function? I don't understand wery well what you mean, but if that's not so damaging for my brain and if i'll understand it, may be i'll made it for you.
Basicaly if you only need mutexes you can do them right now [not a true mutex, but something wery wery close to it].
With a little effort i think i/you/we can add mutexes to the library, but i need to understand why 8p
Actualy i've a dream more than a project in my mind.
What about your project? I'm always looking for people to develope with!
I'm glad to hear you're thinking of making the lib gpl-compatible -- it'll make my life easier. By yield_thread I mean I want to be able to immediately call the scheduler and give up the rest of the timeslice to some other thread. So if a thread is trying to claim a mutex and it's already locked, for example, it doesn't have to waste any more time. I don't know ARM assembly so I don't really understand enough about the scheduler to hack this in myself.
I actually implemented mutexes and condition variables the other night. (I'd be happy to send you patches if you're interested.) They'd be more efficient if there was a yield function, but they should work even without it. (I say *should* work because I haven't tested them yet!) I also implemented thread_wait to allow a thread to block until another thread finishes. I think that's almost enough to fill in the missing threading support for the ds port of the SDL library, which is part of my goal.
My project is a port of the awesome game "The Ur-Quan Masters", which in turn is a port of the classic "Star Control 2". It should definitely be possible to port it, but it's challenging because the game is multithreaded and a bit bloated considering it's actually a pretty simple game. If you're interested in helping out that would be awesome -- I'm not going to be able to spend as much time on this as I'd hoped.
PS: I'm a Mac user too... :-)
Ho, what great news!
I've chose for the GPL, in a few hour i'll upload a new version.
I think that if you whant to make a yield_thread function you can simply:
void yield_thread(void)
{
dispatcher();
}
I THINK IT WILL WORK, but i'm not so shure.
Now, i'm very very interested in your mutexes and condition variables patch! Send me them and i'll include them in the next version [clearly i'll mention you in the library].
I can also test all your function [plus the yield one] if you wish.
"The Ur-Quan Masters" look so cool, but i don't find any tecnical description of the game. It's a turn based strategy game if i don't misunderstand. Why do you need thread? Hope the very best for the work, keep me informed about the project.
All is up and waiting for you 8)
Next, the library is waiting for your patch and some test for the new version.
Hope it can help with your work, i'll do all what i can to help.
I'm under exams and i've that f*****g great big project so sorry, but i cannot help you with the code in your project.
My patch is available here: http://pastebin.org/29738
It *really* needs testing. I haven't even built it yet!
I added the yield function that you described, but I'm not so sure it'll work. Doesn't the arm have a different cpu state when it's handling interrupts?
Where did you get the idea that UQM is turn-based strategy? :-) It's a space exploration/combat game. There's not really anything turn-based in the game. You should try playing it when you have some time -- the game is fun and the plot is really good. (Then maybe you'll come help me port it... :-)
As for why it needs threads, the existing code is based on an old port to the 3DO console. Apparently that console used massive multithreading in its API, so there were lots of threads. The number has gone down over time but there are still threads remaining in the code that would be annoying to remove, so the devs aren't in a rush to get rid of them. One strategy for a DS port would be to remove the remaining threads, but I thought it would be worth a shot to try a threading library first.
I'm sorry, but can you upload a clear version of it so i can merge our work? And try it of curse.
I figured out the game was turn-based ... dunno why and dunno where hehehehe i'm sorry. I'll try it.
3DO, never hear of it, but i think that your tecnique it's good. If our final library will work, than the job will be fast and easy.
If you scroll to the bottom of the pastebin.org link there's a plain text version.
Hummmm ...
I've find only a plain text version of the diff, no straight code. At the bottom there is a tetbox to send message and nothing more. May be i've to login?
OH, I see, you want the whole files. I assumed it would be easier to work with diffs. Where should I send the files?
You can send it directly to my mail
samelinux [ at ] gmail [ dot ] com
I'm sorry, but without the original files it's hard to work with diff 8)
They are diffs against your files, so you do have the originals. But it's not that hard to send a zip... :-)
Thanks for the mail, now i'm under exams so until next week i cannot test the whole library.
As soon as possible i'll post here some comment.
See you soon!
You must log in to post.