Pre-submission enquiry: C++ thread pool library

[bshoshany]

Hello,

I am the author of a C++17 thread pool library, intended for use in high-performance scientific computing. I recently posted a paper about it on the arXiv. I am interested in publishing a paper about it in JOSS, to increase exposure and reach more researchers who may be interested in using the library in their research software.

However, I am not sure if it satisfies the journal's minimum requirements, since this page says that "single-function packages are not acceptable". Please let me know if you would consider publishing a paper on my thread pool library in your journal.

Thanks, Barak Shoshany

[danielskatz]

I see 2 potential issues:

1. The software is very small and has very few commits, so it does not appear to meet the substantial scholarly effort criteria.
2. Is this software research software? Does it have an obvious research application?

[bshoshany]

Thanks for your reply!

1. The repository has few commits because, as I'm the only contributor, I find it easier to edit the code locally and only commit when I decide I have enough new features for a new release, and after doing extensive testing to make sure the update did not introduce any bugs or other issues. My local Git repository has a few hundred commits over the last 6 months or so.
2. The library is meant to enable high-performance multithreading in scientific applications such as simulations, statistical analysis, and so on. I am a theoretical physicist and I originally wrote this library to use in my own research, particularly in software I'm currently developing for visualization of spacetimes in general relativity using relativistic ray-tracing, which relies heavily on multithreading and will run on an 80-thread Compute Canada node. I decided to post the thread pool as a standalone library online a few months ago, and it appears that many people have been using it. This prompted me to post about it on the arXiv, and to look for a suitable journal to publish it in.

[danielskatz]

1. When (if) you submit, it would be good to mention the commit and time history. It would then likely go through a scope query, where the editors discuss it over a week or so and come to a decision.

2. The submission would be need to include a Statement of Need, which could highlight a few specific research problems where the software is needed/used, in addition to making a more general case for it.

[bshoshany]

I see. So, to be clear, you are saying that I should submit the paper, and it will not be rejected outright, but whether it gets accepted or not depends on the editors' decision. Is that correct?

[danielskatz]

That's my opinion, but I would like to hear from @arfon or someone else on the @openjournals/joss-editors team for confirmation

[bshoshany]

Thanks. I will wait for their confirmation before I submit my paper.

[jgostick]

The hpp files is 498 lines TOTAL, which is already short for C-code, and much of that file is comments, so it's really only a few hundred lines of actual code. This does not seem to meet the criteria, though the readme is very detailed and the author seems to have packed a lot of features/functionality into those lines.

[bshoshany]

Perhaps I should mention that making the code as short as possible was an explicit design choice, in order for the thread pool to have the smallest memory footprint possible. The total lines of code in the current version, excluding comments and blank lines, is 238 in total, or even less if we don't count the two optional helper classes - but that's not a bug, it's a feature that I worked quite hard to achieve.

[gkthiruvathukal]

I took a quick look at this project and think it actually is an example of why we can't always look at code size as a measure of effort. Small can be beautiful--and powerful.

In a now bygone era, I co-developed a concurrent library (pre-JOSS era, bummer), JHPC, which was cited as related/prior art by the authors of the Java JSR-166 specification for concurrent utilities. While the idea of a thread pool is not new--and was included in our Java library among many other techniques--it seems to be nicely done in this project with a similar lightweightness to what we envisioned for parallel and distributed computing in Java. I also have a soft spot for documentation, and the pages are extremely detailed and well put-together. At a minimum, I'd consider the docs to push beyond what our normal thresholds are in terms of code size.

Not that I really need more work, but I would be willing to act as editor for this submission, should it be determined that this meets the substantial scholarly effort criteria.

[mjsottile]

I also took a look and came to the same conclusion as @gkthiruvathukal : code size is not a good measure of effort and utility sometimes. In some cases, shorter and more concise implementations reflect a higher degree of effort in order to achieve brevity. (I regard a good day of coding to be one where I end up with equivalent or increased functionality with less lines of code than I started with!)

With respect to the technical content, concurrency control is hard to get right, so bigger usually means harder to reason about correctness. Code complexity is generally considered the opposite of what you want in a system where correctness is hard to reason about.

[bshoshany]

Thanks @gkthiruvathukal and @mjsottile! I'm glad to hear that. So would you recommend that I try to submit a paper about this library to JOSS for consideration?

[gkthiruvathukal]

@danielskatz is one of our EIC's, so I would defer to him for the final bit of encouragement, but I am definitely in the camp that would encourage you to do so and and think it is within scope.

[danielskatz]

Yes, please go ahead. Maybe mention this issue https://github.com/openjournals/joss/issues/918 when you do so