Runtime modifications to a published service

[fadedreamz]

Dynamic publishing of new URI resource after a service has been started

Current implementation does not allow to change the published service.

[ben-crowhurst]

Hey, If you have any questions regarding the implementation don't hesitate to get in contact. We shall offer as much support as we can.

[ben-crowhurst]

Linking original StackOverflow question for completeness.

[fadedreamz]

If the service is running on a single threaded mode or a multi-threaded mode (lets say 4 workers); is it possible that the number of threads accessing the paths and the methods will exceed the number of allowed workers in service_impl?

[ben-crowhurst]

Users can set any thread limit via void set_worker_limit( const unsigned int value );

[ben-crowhurst]

The safest approach is to lock the resources via a std::mutex. This will block the service when engaged and should be held for the shortest possible duration.

[fadedreamz]

Yes, I first I thought so, but this will have a very bad performance impact on a multi-threaded service. Even if there is no changes, one thread will be blocking another thread from reading the paths and methods. I am thinking to find some other good approach to minimize the impact.

[ben-crowhurst]

Why not only lock the resources when writing? Anything that doesn't intend to write shall just have to check if its clear to move ahead, otherwise schedule itself for processing at a later date.

[fadedreamz]

Yes, I was thinking the same, doing some sort of combination of reading_counter and lock to enable lock for readers when the writing is going on, otherwise just execute the code. But I will go according to your suggestion. Thanks

[ben-crowhurst]

Have a look at Service::schedule( ); That will place the task back on the run-loop for later processing. Alternatively you could use Session::sleep_for but you'd have to guess how long to sleep for.

[fadedreamz]

I tried to lock the resource before writing and reschedule the reading function, but Service::schedule() does not take any parameters. Although Session::sleep_for() should be able to do the required task. So, instead of going for guess work; I did implement the combination of reader_counter and lock in service_impl; wrote a sample example and tested it.
Here is the test result for make test
99% tests passed, 1 tests failed out of 109
Total Test time (real) = 16.63 sec
The following tests FAILED:
58 - runtime_service_modifications_acceptance_test_suite (Failed)

I have to do a smoke test with curl script.

[fadedreamz]

Hi how can I perform pull request for code review?

[ben-crowhurst]

Please review Creating a Pull Request.

[fadedreamz]

#165