On Tue, Jun 28, 2011 at 1:40 AM, Daniel-Constantin Mierla <span dir="ltr">&lt;<a href="mailto:miconda@gmail.com">miconda@gmail.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hello,<div class="im"><br>
<br>
On 6/26/11 10:15 PM, Matthew Williams wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Daniel,<br>
<br>
Am I correct that t_continue continues processing in the process that calls it? If so, would it make sense for the async module to have an api for other asynchronous modules to hand off to its worker pool before calling t_continue? Or would it be better for each module to have its own pool of workers?<br>

</blockquote></div>
right now the workers in async module are dummy timers to handle async delayed execution of next actions or specific route block. But there can be coded a single pool of workers and timers for async processing, might be a better solution overall.<br>
</blockquote><div><br>
<br>
I do think a common async worker pool would be a good solution. 
Otherwise, each module that implements async operations will need its 
own pool. <br>
<br>
What do you think, should the async module export an API function such as:<br>
<br>
int async_continue(int thash, int tlabel, void* data, int (*data_handler)(void*));<br>
<br>
This would allow for optional data to be processed by a callback function within the context of
 the worker process before t_continue is actually called.<br>
<br>
Matthew Williams<br>
Flowroute LLC <br></div></div>