As far as I can tell, your needs might be better served by
std.concurrency.
On 9/10/2010 4:21 PM, Michel Fortin wrote:
Le 2010-09-10 à 14:29, David Simcha a écrit :
I have yet to really have feedback from anyone anywhere about it besides
scientific computing people.
Well, I'm not sure how useful is this feedback, but I want to say that the
task-based approach you've implemented can be very useful for GUI applications
that want to do something in the background. I'm working on such an application
right not, it's not in D unfortunately so I can't test your library with it,
but the pattern is always like this:
main thread:
start_task(&task, data, object_to_notify_in_main_thread)
task (data, object_to_notify_in_main_thread):
perform some operation with data (often IO operations)
notify_in_main_thread(object, results)
main thread:
event loop receives notification and calls some function on the
object
So at first glance it seems your library implements the right pattern for me,
at least the first part: spawning a task. The second part, the
notify_in_main_thread operation, basically sends a message to the main thread's
event loop that then calls some function on the given object.
That said, on OS X I would probably try to use the system's built-in task
library (libdispatch, or Cocoa's NSOperation) as it'll use feedback from the
kernel to better manage the load (taking into account the load from other
running processes and whether some tasks threads are blocked on IO to tell
whether new threads should be spawned).
So the question is: how easy would it be to use a different backend for the
thread pool when you want it?
_______________________________________________
phobos mailing list
[email protected]
http://lists.puremagic.com/mailman/listinfo/phobos
