Allow for configurable, custom queue type via template parameter

[cjappl]

No description provided.

[cjappl]

@atsushieno - I updated this and got it to work with an older version of clang, will you check it out again?

[atsushieno]

Thanks @cjappl. I have some attempt to use it with the new QType but stuck at fixing my class for the try_enqueue() contract somehow. I'll revisit there later but if you have any ideas please let me know... :

In file included from /Users/atsushi/sources/rtlog-cpp/test/test_rtlog.cpp:1:
/Users/atsushi/sources/rtlog-cpp/include/rtlog/rtlog.h:144:17: error: static assertion failed due to requirement 'detail::has_try_enqueue_v<rtlog::FarbotMPSCQueueWrapper<rtlog::BasicLogData<rtlog::test::ExampleLogData, 256>, 512>>': QType must have a try_enqueue method
  144 |   static_assert(detail::has_try_enqueue_v<InternalQType>,
      |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/Users/atsushi/sources/rtlog-cpp/test/test_rtlog.cpp:88:7: note: in instantiation of template class 'rtlog::Logger<rtlog::test::ExampleLogData, 128, 256, rtlog::test::gSequenceNumber, rtlog::rtlog_MPSC>' requested here
   88 |       logger;
      |       ^
1 error generated.

edit: the changeset is atsushieno@f5cf022 (also auto-linked from the commit ^)

[cjappl]

Alright, I have a compiling version here:

https://github.com/cjappl/rtlog-cpp/tree/atsushieno_test

I still need to poke at it a bit, but I tried to make the checks more explicit, and this helped me catch a few things that are off. Let me know if this works for you, or I'll report back later with more info!

In case you're curious, the original problem was your class did not have a value_type member, which is what this try_enqueue SFINAE was looking for! I added an explicit check for that, so hopefully the error message is more clear. If you check out the static asserts, it should be super explicit what a queue specialization needs

[atsushieno]

Ahh, with your detailed explanation now everything makes sense to me. Thank you so much! I haven't tried your exact code but locally confirmed the core change by adding value_type field (just like what readerwriterqueue does), up to the tests passing.

If you don't mind, I would just hand over the rest and the overall changes (assuming that the rest of the work does not bother you. I don't care my commits remain or not). Of course if there's anything I can I'm happy to help here.

[cjappl]

Awesome, glad to hear it.

I want to get your feedback: does this design make sense to you? As a user is it easy enough to incorporate a new queue if you wanted to? Is there any other changes to the interface that would make this more obvious or easy to use?

Thanks for all your help with this one, I think a change to allow users to specify their own queue really improves rtlog, and I wouldn't have done it without your help.

[cjappl]

@atsushieno I incorporated your work here as an example for future readers. Would you please review this?

I'll make sure you get marked as a co-author in the git commit, as I took much of this verbatim from your branch :)

[atsushieno]

Yes everything looks much greater with the customizible queues! I'm glad my changes were of some help.

I don't try hard to push my MPSC stuff in the main code from "example use case", but what I'm concerned however is that people would like to have default implementation for MPSC anyway, and they would simply ask you to incorporate that farbot version (or anything equivalent) after all, just like there is the original SPSC implementation.
For my own purpose I will keep my friendly fork version (maybe not even a fork, just an addon header would work), and I'm a bit concerned that it may be more widely referenced than your original repo as people would usually want to use the logging functionality in multi-threaded apps.
As a library author in this world I understand that I wouldn't like to incorporate external deps that might not match my taste (or being asked to do so), but having third-party fork more popular (especially widely used without my fixes) would not be a great experience.
IF that were the case in the future, I'm always happy to share my stuff and feel free to take them back into this repo.

[cjappl]

That makes sense.

How about this: I submit this change, then either myself or you (if you had time and wanted to) "swap" farbot and readerwriterqueue. Farbot becomes the main dependency, we add two versions of the wrapper - one single producer and one multi-producer. readerwriterqueue becomes the example dependency.

Overall, my only concern with incorporating farbot AND readerwriterqueue together is that we would be downloading more dependencies to user's machines. I already feel partly bad downloading stb, libfmt AND readerwriterqueue. Most libraries I know and trust don't download anything and are "self reliant". I would like to not add additional dependencies to the mix if possible. I agree that it is reasonable for users to want both single producer and multi producer versions of rtlog.

If we swapped in farbot as the primary queue, this would keep the dependency count the same and add more flexibility for the user. It would also be easy for anyone to add a new queue on their own if they wanted it.

What do you think?

[atsushieno]

That would be the best solution I agree :-)
I'm working on some other stuff now, but when I have time and if it's not done then I'll take the task (I don't mind overlaps, wouldn't waste too much time anyway).

[cjappl]

Sounds good. I'll ping you in any reviews if I take on the work, please do the same for me!

[atsushieno]

As a user is it easy enough to incorporate a new queue if you wanted to? Is there any other changes to the interface that would make this more obvious or easy to use?

With the actual use case (farbot), I'm sure it is fairly easy to understand. The detailed description you left here in this issue would also help too :-)