If ast_threadpool_set_size with a size equal to the current size, a
reference to a set_size_data structure would be leaked.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382555 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Ownership of the listener reference is not transferred because the
listener is reffed when placed into the taskprocessor. Ensure that the
listener is dereffed properly.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382489 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds the ability to create a serializer from a thread pool. A
serializer is a ast_taskprocessor with the same contract as a default
taskprocessor (tasks execute serially) except instead of executing out
of a dedicated thread, execution occurs in a thread from a
ast_threadpool. Think of it as a lightweight thread.
While it guarantees that each task will complete before executing the
next, there is no guarantee as to which thread from the pool individual
tasks will execute. This normally only matters if your code relys on
thread specific information, such as thread locals.
This patch also fixes a bug in how the 'was_empty' parameter is computed
for the push callback, and gets rid of the unused 'shutting_down' field.
Review: https://reviewboard.asterisk.org/r/2323/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@381326 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Add a max_size option for threadpools. Also added a test for this option.
* Fixed comments to be more accurate and have fewer typos.
* Updated copyright dates on new files.
git-svn-id: https://origsvn.digium.com/svn/asterisk/team/mmichelson/threadpool@379375 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Clarify some documentation
* Change copyright date of taskprocessor files
* Address potential issue of creating taskprocessor with listener if
taskprocessor with that name exists already
git-svn-id: https://origsvn.digium.com/svn/asterisk/team/mmichelson/threadpool@379124 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Now user data is allocated by the creator of the taskprocessor
listener and that user data is passed into ast_taskprocessor_listener_alloc().
Similarly, freeing of the user data is left up to the user himself. He can
free the data when the taskprocessor shuts down, or he can choose to hold
onto it if it makes sense to do so.
This, unsurprisingly, makes threadpool allocation a LOT cleaner now.
git-svn-id: https://origsvn.digium.com/svn/asterisk/team/mmichelson/threadpool@379120 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Remove extraneous whitespace
* Bump up debug levels of messages and add identifying info to messages.
* Account for potential failures of ao2_link()
* Add additional test and some more test data
* Add some comments in places where they could be useful
* Make threadpool listeners and their callbacks optional
git-svn-id: https://origsvn.digium.com/svn/asterisk/team/mmichelson/threadpool@378652 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The documentation for taskprocessors was incorrect with
regards to when a listener's alloc callback was called.
I also made the names of queued function calls in the
threadpool more uniform.
git-svn-id: https://origsvn.digium.com/svn/asterisk/team/mmichelson/threadpool@377802 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Unfortunately, this required a taskprocessor listener change that makes listener allocation
utterly silly. I'm going to change the scheme so that allocation of taskprocessor listeners
is done internally within taskprocessor code. This will make it parallel with threadpool
code, which is a good thing.
git-svn-id: https://origsvn.digium.com/svn/asterisk/team/mmichelson/threadpool@377687 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The only test added so far is an idle thread timeout
option. This will greatly aid threadpool users who wish
to maintain a threadpool by allowing for idle threads to
die out as necessary.
Test passes.
git-svn-id: https://origsvn.digium.com/svn/asterisk/team/mmichelson/threadpool@377580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This helps tests to pass more often than before.
They are far less likely to queue extra processes
into the control taskprocessor since they are prevented
once the threadpool begins to shut down.
git-svn-id: https://origsvn.digium.com/svn/asterisk/team/mmichelson/threadpool@377578 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This one involves shrinking the threadpool in such
a way that both idle and active threads are affected.
This test made me re-realize why the zombie state exists,
so I re-added it. We don't want to clog up the control
taskprocessor by waiting on active threads to complete
what they are doing. Instead, we mark them as zombies so
that when they are done, they can clean themselves up
properly.
Without the zombie state available, the new test actually
will deadlock.
git-svn-id: https://origsvn.digium.com/svn/asterisk/team/mmichelson/threadpool@377474 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The new thread creation test fails because Asterisk locks up
while trying to lock a taskprocessor.
While trying to debug that, I found a race condition during taskprocessor
creation where a default taskprocessor listener could try to operate on
a partially started taskprocessor. This was fixed by adding a new callback
to taskprocessor listeners.
Then while testing that change, I found some bugs in the taskprocessor
tests where I was not properly unlocking when done with a lock. Scoped
locks have spoiled me a bit.
I still have not figured out why the threadpool thread creation test
is locking up.
git-svn-id: https://origsvn.digium.com/svn/asterisk/team/mmichelson/threadpool@377368 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After giving it some consideration, there's no real
use for zombie threads. Listeners can't really use the
current number of zombie threads as a way of gauging activity,
zombifying threads is just an extra step before they die that
really serves no purpose, and since there's no way to re-animate
zombies, the operation does not need to be around.
I also fixed up some miscellaneous compilation errors that
were lingering from some past revisions.
git-svn-id: https://origsvn.digium.com/svn/asterisk/team/mmichelson/threadpool@377211 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Since threadpool shutdown is very strictly controlled,
there is no need to be so precise with reference counts
in queued operations. Since the threadpool shuts down its
own control taskprocessor before doing anything else destructive,
it can be guaranteed that all queued tasks will have a valid
pointer to the pool. This meant that some destructor functions
for helper structs could be removed entirely.
git-svn-id: https://origsvn.digium.com/svn/asterisk/team/mmichelson/threadpool@377210 65c4cc65-6c06-0410-ace0-fbb531ad65f3