Hi David,
Le 10 janv. 07 à 22:41, David Chisnall a écrit :
I have given a copy of my XMPP code to Jesse (to prove that it does
actually exist).
Cool :-) Do you have a basic chat application or some other kind of
softwares you have developed along with it?
There are still a few bugs that are irritating me (and a few more
that aren't), but I expect to move it to the Étoilé repository soon.
ok. You can put it in a branch before moving it to trunk if you feel
the code isn't ready yet. Not implying all the code in trunk is ready
for consumption ;-)
Sometime in June, I was at a conference in Dublin and, in the
absence of anything fun to do in the evenings, I turned my
attention to the lamentable state of threading in OpenStep. POSIX
provides a very rich set of threading APIs, and OpenStep... doesn't.
My first task was to implement ETThread, a class that is marginally
more useful than NSThread, in that you can wait for it to finish
and return a value, get the current thread, etc.
Once this was working, I began playing with the idea of
implementing futures in Objective-C. I'd heard that you could do
them in Smalltalk easily, but Objective-C lacks a few of the
features of Smalltalk. I began by adding a category to NSObject
that adds a +threadedNew method. This creates an instance of an
object in a new thread, and returns a proxy object.
Any message you send to the proxy object will then be passed on to
the real object, which can then complete it asynchronously. What
about methods that return a value? Well, in this case, the proxy
returns a(nother) proxy object (so I don't get confused talking
about multiple proxies, we'll call this one the future)
immediately. When the method completes, it will set the value for
the future.
This is a really nice addition because I fully agree with you about
thread support in Foundation being rather awfull.
It reminds me HOM stuff as implemented by Marcel Weiher in
MPWFoundation, where you can write code like result = [[myObject
inNewThread] doSomething]
May be you already aware of it. You can find more details on
cocoadev.com
Any messages passed to the future before the method completes will
simply block until it does. Any sent after will be transparently
passed on. This means you can perform the following set of
operations transparently:
1) Create an object in a new thread, with its own run-loop.
2) Fire a message at the object.
3) Do some other stuff while it is processing on your other core.
4) Do something with the return value, blocking automatically until
2) completes.
What are the limitations?
- Currently, only methods that return void or objects return
asynchronously. Methods that return intrinsics (including pointers
to non-objects) will block until the method completes.
Not really dramatic since we can wrap such intrisics into objects.
- Thread locking is quite expensive, so if your method returns
quickly then this can be slower than doing it in the same thread.
Probably overkill for now, but a solution could be to have the
possibility to use either OS threads or lightweigth threads for a
threaded object.
Io language which is included in Étoilé relies on lightweigth threads
(called coroutines) to implement concurrency and futures, but
provides OS threads as a addon. It uses a standalone coroutine
library to implement its concurrency model, it is available here:
<http://www.dekorte.com/projects/opensource/libCoroutine/>
Otherwise I remember to have read about similar threading library for
Cocoa, here it is: <http://www.frameworklabs.de/protothreads.html>
- You can't mix and match between asynchronous+futures and
synchronous calls to the same object (probably a good thing, or
tracing deadlocks would be a nightmare)
This is surely safer. Though providing something like [[myObject
inNewThread] doSomething] as MPWFoundation does could be useful for
"normal" object.
- Currently it's just distributed as a small sample. It should be
either put into a library, or framework, or rolled into another
framework. On this subject, is there an Étoilé meta-framework that
developers can just include to get access to all the standard
Étoilé shininess, along the lines of the Cocoa framework in OS X?
Not really at this time, but the plan is to put such code into
EtoileUI and EtoileFoundation (already available in svn). Finally we
could also have a umbrella framework called Etoile that would
aggregate EtoileUI, EtoileFoundation and few common frameworks not
part of the two previous ones.
To take an example, for EtoileFoundation, we would have:
- EtoileFoundation/EtoileFoundation.h (umbrella header)
Various utility classes that don't fit in a framework put into
- EtoileFoundation/Headers
- EtoileFoundation/Source
Various frameworks like:
- EtoileFoundation/EtoileThread
- EtoileFoundation/EtoileCollection
etc.
Currently Headers and Source already include some classes, I plan to
push more code into it (for example ETMachineInfo). You can already
find some threading extensions in this framework. It would be nice if
you could work on integrating them nicely with ETThread.
I also think EtoileThread would be a better name than ETThread or
something else without an objc-like prefix.
Finally thanks for this really nice contribution :-)
P.S. I seem to have become unsusbribed from this list at some point
between September and now. Does anyone have any idea why this is?
I thought the list had gone a bit quiet. Now I know why...
Something strange happened back in september with etoile-dev, we lost
the whole member list (probably some GNA related bug). I hope it
won't happen another time :-/
This was mentionned on etoile-discuss and Étoilé News blog. It is
still mentionned on etoile-project.org I think.
Cheers,
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
