Add an alternate method to enqueueAndDetach a task without requiring the capture of std::future<>#31
Add an alternate method to enqueueAndDetach a task without requiring the capture of std::future<>#31Calthron wants to merge 10 commits intoprogschj:masterfrom
Conversation
…rn value Add the ability to enqueue a task that does not require monitoring a return value. std::future<T> on destruction is expected to wait() for a thread to complete before completing destruction (btw, MSVS2103 std::future/std::ansync does not behave according to C++ Standard). If a temporary future is created (not captured), the calling thread should block waiting for the thread to exit and complete the promise. An alternate enqueueAndDetach method was added to allow for invocations that don't require the capturing of the std::future.
Typo in comment
Calthron
changed the title
Break the source into header and implementation, make the template definition more readable by changing F to Callable
Rename ThreadPool.h to ThreadPool.hpp
Comment update
Calthron
changed the title
Calthron
changed the title
Use typename instead of class
Provide a single exit point for the worker thread
Use lock_t instead of Lock
ThreadPool.hpp
Outdated
|
|
||
| // Don't allow an enqueue after stopping | ||
| if (stop) | ||
| throw std::runtime_error ("enqueue on stopped ThreadPool"); |
There was a problem hiding this comment.
@progschj isn't this going to cause a throw from destructor potentially? that seems to the be only time when "stop" is called. IIRC you can never cleanly catch such an exception -- DTOR throw is undefined behavior.
There was a problem hiding this comment.
I’m not sure I understand the question.
This would be throwing on a caller’s thread when the internal ‘stop’ flag is true, and the caller was trying to add a task. If the caller is calling member functions while the object is being destroyed… that would be another sort of issue.
From: peter karasev [mailto:notifications@github.com]
Sent: Thursday, June 16, 2016 11:56 AM
To: progschj/ThreadPool ThreadPool@noreply.github.com
Cc: Steven LeMay steven.lemay@sbcglobal.net; Author author@noreply.github.com
Subject: Re: [progschj/ThreadPool] Add an alternate method to enqueueAndDetach a task without requiring the capture of std::future<> (#31)
In ThreadPool.hpp #31 (comment) :
- // Notify a thread that there is new work to perform
- condition.notify_one ();
- return result;
+}
+// Add a new work item to the pool
+template<typename Callable, typename... Args>
+auto ThreadPool::enqueueAndDetach (Callable&& callable, Args&&... args)
- -> void
+{- { // Critical section
Lock lock (queue_mutex);
// Don't allow an enqueue after stoppingif (stop)throw std::runtime_error ("enqueue on stopped ThreadPool");
@progschj https://github.com/progschj isn't this going to cause a throw from destructor potentially? that seems to the be only time when "stop" is called. IIRC you can never cleanly catch such an exception -- DTOR throw is undefined behavior.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/progschj/ThreadPool/pull/31/files/f761d527a83a37003ecef53c94718818e60d8601#r67404012 , or mute the thread https://github.com/notifications/unsubscribe/AKJadATwrIy1WhowY4pCzd32mUBhU6JSks5qMZxagaJpZM4GfmQ6 . https://github.com/notifications/beacon/AKJadA15Aixeyyd70laKpBGr_6yKx0KRks5qMZxagaJpZM4GfmQ6.gif
enqueAndDetach is not needed as std::future wait is not an issues on it's destruction if it is not created from std::async.
2 participants
Add a new alternate method to enqueueAndDetach a task without requiring the capture of std::future<>. Note: There is probably a better name for this method, open to suggestions.