Hi Everyone,
As you may have noticed, I am completely rubbish at actually
bothering to commit code. Last year, my New Year's resolutions were:
- Be better at committing code, and
- Fill in my tax return more than a month before the final deadline.
Since I failed both of them, I am recycling them for this year. The
second one doesn't concern this project. The first one, however,
does. So far:
I have given a copy of my XMPP code to Jesse (to prove that it does
actually exist). 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.
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.
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.
- Thread locking is quite expensive, so if your method returns
quickly then this can be slower than doing it in the same thread.
- 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)
- The code is quite inefficient. I've done the 'make it work' phase;
the 'make it fast' bit comes next.
- 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?
The code is now in svn, for everyone to play with. Grab it from:
etoile/Etoile/Frameworks/ETThread (in trunk)
Enjoy!
David
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...
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
