control.thread-pool add-job! with timeout
Shiro Kawai <shiro <at> lava.net>
2011-01-07 08:04:22 GMT
This is a polling question. Is there an objection if
I change the behavior of add-job! in control.thread-pool?
A thread pool implementation control.thread-pool is a new
feature in 0.9.1. With it, you can specify the maximum backlog
size of input job queue (default is unlimited). It is sometimes
handy to have limited backlog to regulate speeds among different
The API to enter a new job to a pool is add-job!. Somehow I
designed it in a way that it returns immediately when the
pool's input queue is full, returning #f indicating so.
Now I think it should block until there's a room in the
input queue by default, and take an optional timeout argument.
It will be consistent with various other thread APIs such as
thread-join!, mutex-lock!, and enqueue/wait!.
The change will break the code that expects add-job! to
return upon full backlog situation, but I feel it's better
to have the consistency, and it is less painful to change
it now than later.
The change won't affect the code that uses a thread pool
without backlog limit; in which case add-job! always
returns immediately, putting a new job into the queue.
A similar discussion may be applicable to wait-all; there's
not way to specify timeout now. Current check-interval
argument is less important than timeout, so I'd like to