v3.0

[eidheim]

Please see #134 for information on the changes.

I'll do a v2 minor release before releasing v3.

Let me know what you think of the changes in this PR. Testing feedback is also welcome!

edit: typo edit2: removed old issues

[eidheim]

Currently, I'm doing some tests to see if it is feasible to let users construct Server and Client objects like before (without ::create that returns a shared_ptr). I think I'm done with the Client code, and if it seems to be ok I'll start on the Server as well. I had to implement shared mutex, read-preferring R/W locking that is, to make this work without too much overhead. Hopefully, we get equally many requests/sec as before from the server. We'll see.

edit: server code is close to done too.

[eidheim]

My shared mutex implementation seems more expensive than I thought. I'm getting around 59k req/secs on the v3 branch, and around 63k on master... I'll look at this later and see if there is something that can be done.

[jeffreyscottgraham]

Why not use the ones in std namespace?-----Original Message----- From: Ole Christian Eidheim Sent: Jul 5, 2017 3:32 PM To: eidheim/Simple-Web-Server Cc: Subscribed Subject: Re: [eidheim/Simple-Web-Server] v3.0 (#139) My shared mutex implementation seems more expensive than I thought. I'm getting around 59k req/secs on the v3 branch, and around 63k on master... I'll look at this later and see if there is something that can be done. —You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or mute the thread. {"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/eidheim/Simple-Web-Server","title":"eidheim/Simple-Web-Server","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/eidheim/Simple-Web-Server"}},"updates":{"snippets":[{"icon":"PERSON","message":"@eidheim in #139: My shared mutex implementation seems more expensive than I thought. I'm getting around 59k req/secs on the v3 branch, and around 63k on master... I'll look at this later and see if there is something that can be done. "}],"action":{"name":"View Pull Request","url":"https://github.com/eidheim/Simple-Web-Server/pull/139#issuecomment-313218426"}}}

[eidheim]

@jeffreyscottgraham std::shared_mutex is c++17 sadly, it didn't even make it to c++14 for some reason. I guess it was a good reason though, but I cannot tell yet, have only studied readers-writer locks for some hours Today. Also, using the boost version is not an alternative, since the header files should work without boost when compiling with standalone asio.

I can't tell if the fair algorithm used in boost/c++17 is faster, I think not actually, since the one I'm using is read-preferring, while the fair algorithm does not have preference. Most likely I have to abandon using shared mutexes because of the overhead. It is a bit sad though, since I'm really happy about how the Client and Server is behaving upon destruction in the v3 branch.

[eidheim]

I ran into this related ticket: https://svn.boost.org/trac10/ticket/11798#comment:8. It's been open for a while. I also tested on Linux, which is mentioned to be slow in the issue, since, like I'm doing, "heavyweight" mutexes are used to guard the shared mutex state.

[eidheim]

Before I give up, I'll try the platform dependent shared locks (pthread shared locks on unix like systems). Their implementation is sured to be based on atomics and should be much faster.

[eidheim]

pthread shared locks are just as slow, so readers-writer locks are out of the question. Back to the drawing board.

[eidheim]

This PR is coming along nicely. There are some added complexity, but concerning the readers-writer lock problem, I solved it by not using it when an internal io_service is used (the most common use case). That is, the shared mutex is only needed when the lifetime of the io_service is not known by the server.

There is also the possibility later to write a faster readers-writer lock for our use case, but that will require some research. Extra information if someone is interested in this: the lock should be highly optimised for readers.