On 11 Jan 2007, at 10:47, Quentin Mathé wrote:
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?
Yes, the chat application I've been using on OS X for the past year.
It only really does basic presence and messaging at the moment, but I
refactored the XMPP code a lot near the end of last year to make it
easier to add more features. I haven't done the GNUstep port yet;
last time I tried the nib file support wasn't there and there was a
bug in GORM that stopped it reading my headers (fixed now).
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 ;-)
Well, on OS X, it works enough to use, but occasionally gets into a
broken state and needs re-starting.
This is a really nice addition because I fully agree with you about
thread support in Foundation being rather awfull.
I'm not entirely convinced by threading as a model for concurrency,
but it's okay as a foundation. Distributed objects are probably
better, but they aren't transparent to the developer, which means
they don't get used as often as they possibly should.
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
Hmm. I vaguely remember Nicolas showing me something a bit like that
a while ago...
- 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.
It would be trivial to add auto-boxing for intrinsics. I didn't do
this (although there's a //TODO in the code where it can be added),
however, because it would break transparency. Currently, you can put
the root object for an object graph in a new thread and act with it
as though it were a synchronous object. The only limitation is that
you might get some strange results if it then calls messages in
objects in your main thread. If I added auto-boxing, the code that
called the method would have to be aware that the return type had
changed.
- 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>
Co-routines don't actually provide real concurrency though, which
more-or-less defeats the point of this. They provide the appearance
of concurrency to the developer, but since they don't rely on on the
OS they don't let you use your second core.
I can eliminate most of the locking by using a static array of ids as
a ring buffer and using atomic increment instructions (although this
is going to result in some architecture-dependent code, which is
slightly irritating).
- 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.
Actually, I forgot to mention, I did implement an -invokeInNewThread:
method in the category on NSObject. If you manually construct an
NSInvocation, you can have it complete in a new thread. The down
side is that it's not transparent, however it would be quite easy to
add a -inNewThread method that returned (yet another) proxy object
that implements the -forwardInvocation: method to this method.
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.
Feel free to shuffle the code in to a different part of the
repository. It could do with some more testing (the sample program
is really the only thing I've done with it yet), but making it
available to developers seemed like a good way of doing this.
By the way, another thing that I was working on was serialisation of
arbitrary objects. By inspecting the type information associated
with each object, I have written code that will automatically
serialise almost any arbitrary object with no input modifications
(the exceptions are pointers to things other than classes, since the
size of the allocation is not stored at runtime[1]). Still to do is
the deserialisation code...
I hope to put this stuff in SVN soon.
[1] Actually, it is on OS X, but not on most platforms. Even so, it
would still be likely to break with double-indirections, so it's
better to leave it to the developer.
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
