Sorry if you receive this message twice, but my first post seems to
have been lost.
Le 11 janv. 07 à 12:18, David Chisnall a écrit :
On 11 Jan 2007, at 10:47, Quentin Mathé wrote:
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.
ok
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.
Making them more transparent may open new use (this was one of the
idea behind CoreObject, but the development is currenly in an idle
period).
- 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.
ok, not sure it is worth the investment, eventually a method like -
turnOnAutboxingIfThreaded may be added.
I was just suggesting the developer can write a new method that takes
care of wrapping the instrisic return value into an object. Then he
would call this method when the object is used in a threaded fashion.
For example:
- (int) giveMeAnInt { return 5 }
- (NSNumber *) giveMeANumber { return [NSNumber numberWithInt: [self
giveMeAnInt]] }
The code would call -giveMeAnInt in a threaded fashion like this:
NSNumber *boxedInt = [threadedObject giveMeANumber]
Just by curiosity, do you have other ideas to support intrisic return?
- 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.
But sometimes I think it could be sufficient (and potentially more
efficient than a real thread, not sure of this point though). For
example you need to run a method that would block the main thread for
one second (or half a second), having such coroutines is useful to
eliminate tiny UI chockes that are very common. I would say that
migrating such thread to a second core would be too expansive to
present an interest, no?
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.
ok. At some point, I will surely move it into EtoileFoundation.
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...
This seems really interesting, looking forward to it :-)
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
