Skip to content
This repository has been archived by the owner on Jun 12, 2018. It is now read-only.

thread safe example for Fileserver #215

Open
kinimodmeyer opened this issue Feb 28, 2018 · 7 comments
Open

thread safe example for Fileserver #215

kinimodmeyer opened this issue Feb 28, 2018 · 7 comments

Comments

@kinimodmeyer
Copy link

kinimodmeyer commented Feb 28, 2018

could you provide a thread safe example of the FileServer-Class? :)

@eidheim
Copy link
Owner

eidheim commented Mar 1, 2018

I think these changes should work without creating a buffer for each send operation, although c++14 is required here:

diff --git a/http_examples.cpp b/http_examples.cpp
index 3e16a9c..39ad46c 100644
--- a/http_examples.cpp
+++ b/http_examples.cpp
@@ -173,16 +173,17 @@ int main() {
         // Trick to define a recursive function within this scope (for example purposes)
         class FileServer {
         public:
-          static void read_and_send(const shared_ptr<HttpServer::Response> &response, const shared_ptr<ifstream> &ifs) {
+          static void read_and_send(const shared_ptr<HttpServer::Response> &response,
+                                    const shared_ptr<ifstream> &ifs,
+                                    vector<char> &&buffer) {
             // Read and send 128 KB at a time
-            static vector<char> buffer(131072); // Safe when server is running on one thread
             streamsize read_length;
             if((read_length = ifs->read(&buffer[0], static_cast<streamsize>(buffer.size())).gcount()) > 0) {
               response->write(&buffer[0], read_length);
               if(read_length == static_cast<streamsize>(buffer.size())) {
-                response->send([response, ifs](const SimpleWeb::error_code &ec) {
+                response->send([ response, ifs, buffer = move(buffer) ](const SimpleWeb::error_code &ec) mutable {
                   if(!ec)
-                    read_and_send(response, ifs);
+                    read_and_send(response, ifs, move(buffer));
                   else
                     cerr << "Connection interrupted" << endl;
                 });
@@ -190,7 +191,7 @@ int main() {
             }
           }
         };
-        FileServer::read_and_send(response, ifs);
+        FileServer::read_and_send(response, ifs, vector<char>(131072));
       }
       else
         throw invalid_argument("could not read file");

@kinimodmeyer
Copy link
Author

@eidheim nice that works great 👍 (maybe adding into the example?)

btw how is the threading working exactly in this lib?
is there a logic that every thread execute his own lambda-call or can multiple threads execute the same lambda-call?

@eidheim
Copy link
Owner

eidheim commented Mar 1, 2018

In general, it is best to use an event loop (one server thread) so that all the handlers that you define always will be run sequentially. But this does not mean that your application is running in only one thread, because Asio is using internal threads for for instance tcp/ip communication. In other words, the number of threads you define in the config object, is the number of threads that will be used to run your handlers such as the resource functions and the send-method argument.

@eidheim
Copy link
Owner

eidheim commented Mar 1, 2018

Here is an another attempt, where the number of buffers created equals the maximum number of threads the handlers are run in: 

edit: removed flawed diff

@kinimodmeyer
Copy link
Author

that means, that one server.resource[xyz][xyz]-callback only getting executed by one thread
(no matter how much you defined in config)

with more threads in config, more threads can work on these callbacks but 2 threads not executing the exact same connection-callback?

@eidheim
Copy link
Owner

eidheim commented Mar 1, 2018

With 2 threads in config, 2 callbacks, any callbacks that is, similar or not, can be executed simultaneously, so if you use shared resources, keep in mind to protect them using mutexes or something similar.

With 1 thread, event loop that is, the handlers/callbacks are run sequentially, no need to think about mutexes in your callbacks.

@eidheim
Copy link
Owner

eidheim commented Mar 1, 2018

I see you point now, and yes my last attempt is flawed. I'll edit it.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants