From 0194d803e2371f2f92ca137b934e2dc4d1bfa3de Mon Sep 17 00:00:00 2001
From: John Cupitt <jcupitt@gmail.com>
Date: Mon, 22 Mar 2010 15:38:17 +0000
Subject: [PATCH] stuff

---
 ChangeLog                         |  1 +
 TODO                              | 44 ++-----------------------------
 libvips/include/vips/threadpool.h |  2 +-
 3 files changed, 4 insertions(+), 43 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index bcc6230f..7be5124a 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,6 +1,7 @@
 21/3/10 started 7.21.3
 - added progress feedback to threadpool
 - --vips-wbuffer2 switch does all wbuffer use now
+- im_wbuffer2() renamed as vips_discsink(), some cleanups
 
 16/1/10 started 7.21.2
 - "invalidate" is careful to keep images alive, so invalidate callbacks can do
diff --git a/TODO b/TODO
index a4665cdd..7f0968c4 100644
--- a/TODO
+++ b/TODO
@@ -1,48 +1,8 @@
-- make VipsRegionWrite the real fun, im_wbuffer_fn the typedef
-
-- try with im_render(), ouch, that will be painful
-
-- switch im_iterate() over?
-
-- do we have other uses of threadgroup?
+- still to move to threadpool: im_iterate(), im_render(), maybe wait for
+  better performance numbers before we move them
 
 - nip2 image display does not work with threading disabled
 
-- try a distributed worker model for image generation
-
-  at the moment threadpools have an idle list and a manager ... in fact, what
-  will generally happen during a run is;
-
-  	* idle list is empty 99% of the time ...
-	* a worker finishes, locks the idle list, adds itself, signals 
-	  on the 'idle' semaphone that someone is waiting, and then waits
-	  itself in 'go'
-	* manager wakes up, locks the idle list, gets the worker, assigns
-	  a task, signals on 'go' and sleeps again on 'idle'
-	* worker wakes up and starts processing again on the new task
-
-  we can make this a lot simpler if we allow workers to assign themselves
-  tasks, something like
-
-  	* worker finishes a tile
-	* worker locks the assign-task mutex, runs a function to set new
-	  parameters, and unlocks
-	* the task can be 'generate a tile' or 'job done, you can quit', or
-	  'there has been an error, abort' or anything really
-	* worker starts on the next thing
-
-  then we need some simple stuff so that the background write thread knows
-  when a buffer is complete: the task-allocate function needs to cooperate
-  with the background writer, not too hard
-
-  so threadpool needs to have a set of threads and a mutex and ... erm that's
-  it, perhaps there's some common stuff we could put in there, quit? error
-  handling?
-
-  make a new thing, junk threadgroup
-
-  VipsThreadPool?
-
 - doing im_create_fmask() and friends
 
 - try writing docs for vipsthumbnail with gtkdoc? then try header etc.
diff --git a/libvips/include/vips/threadpool.h b/libvips/include/vips/threadpool.h
index 7fb1473d..14ab0e8c 100644
--- a/libvips/include/vips/threadpool.h
+++ b/libvips/include/vips/threadpool.h
@@ -84,7 +84,7 @@ int vips_threadpool_run( VipsImage *im,
 void vips_get_tile_size( VipsImage *im, 
 	int *tile_width, int *tile_height, int *nlines );
 
-typedef im_wbuffer_fn VipsRegionWrite;
+typedef int (*VipsRegionWrite)( REGION *region, Rect *area, void *a, void *b );
 int vips_discsink( VipsImage *im, 
 	VipsRegionWrite write_fn, void *a, void *b );