peerreview VS preemptible-thread

Hey everyone, I'm an experienced software engineer from an academic family. I've been aware of the problems in academic publishing for most of my life, and for the last several years I've been running headlong into the paywalls as I work on municipal policy advocacy. I've been pondering software solutions to this problem for a long time. This is exactly the sort of problem internet based software is, in theory, best suited to solving: sharing and discussing information. It should be possible to build a web platform that allows academia to share work, collect feedback, organize review that maintains quality, and find relevant papers with out relying on private, for-profit journal publishers. It should be possible to build and run a web platform that handles all of academic publishing for 1% of the current cost of for-profit publishing or less - which would (in theory) allow the universities to keep it funded while allowing it to be free to publish and free to access. Hell, it could probably be run lean enough that individual academics could fund it through small dollar donations. There's really no good reason to allow the private publishers to charge academia $11 billion a year while keeping 80% of the work locked behind paywalls. I've had several ideas for how to approach the problem, and I spent the last year building out a beta of one of them as a side project. Software development is experimental and iterative. It only works when the developers are able to get active feedback from the people most effected by the problems they are trying to solve. So I'm reaching out for feedback on the beta, and on possible paths forward. The web platform that I've built enables crowdsourced peer review of academic papers. It uses a reputation system (similar to StackExchange) and ties reputation to a field/concept tagging system. Submitted papers must be tagged with 1 - n fields, and only peers who have passed a reputation threshold in one of the tagged fields may offer review. Review is also split into two phases: pre-publish and post-publish. Pre-publish review is author driven. It's focused on collaborative, constructive feedback and uses an interface heavily inspired by both Github Pull Requests and Google Docs. Post-publish review is much closer to traditional review, and is focused on maintaining the integrity of the literature by filtering out spam, misinformation, fraud, and poorly done work. Reputation is mostly gained and lost through voting that happens during post-publish review. Reputation can also be gained by offering particularly constructive pre-publish reviews. All reviews are open and published alongside the papers. Post-publish review is on-going. That's iteration one. As much as I believe review could be crowdsourced, it seems pretty clear that going straight from what we have to this platform would be a huge leap. So I have ideas for how to build a journal overlay on top of the crowdsourced review system that would allow editors to manage teams of reviewers and run their journals through the platform. This would allow them to take advantage of the review interface, and would still give authors the benefit of being able to have a conversation with their reviewers. Authors would then be able to choose to submit their papers to one or more journals, crowdsourced review, or both. Building that out is the next project. Right now I'm working on this as a side project and an experiment -- could a web platform like this work? Would people even use it? If the answer turns out be yes, I'd love for it to become a non-profit, multi-stakeholder cooperative. Essentially independent public infrastructure similar to Wikipedia, only more transparent and more clearly democratically governed. I would love feedback on all aspects of this project - both the current crowdsourcing iteration and the thought to build a generic, open platform for diamond open access journals to run their operations through. Could you ever see yourself using something like this to publish? What about to collect pre-print review? Could you see yourself reviewing through it? What about submitting to journals through it? Are there other approaches to building a web platform that might work better? Am I barking up the wrong tree? Should I press forward, abandon, or is there a better tree? You can find the beta platform here: https://peer-review.io The source here: https://github.com/danielbingham/peerreview And more details about exactly how it works (in its current iteration) here: https://peer-review.io/about Maintaining an open roadmap here: https://github.com/users/danielBingham/projects/6/views/1

And the source code here: https://github.com/danielbingham/peerreview

Last summer I finally saved up enough runway to take some time off work and put a significant amount of time into building an MVP beta of it ( https://peer-review.io, https://github.com/danielbingham/peerreview ). I've been trying to find folks interested in trying it out and exploring whether it could work.

Hey HN,

I've been working on Peer Review for the past year. It's still in early beta (pre-0.1) but I'm looking for some early adopters to start putting it through its paces and help highlight areas I should focus on.

Peer Review is an idea I've had for years. You're probably well aware of the problems involved in academic, scientific, and scholarly publishing - HN certainly discusses them enough. Peer Review is my attempt to solve them (or a subset of them).

Peer Review combines features of Github and StackExchange to allow scholarly review to be crowd sourced to a trusted pool of peers. It does this by tying reputation to a hierarchical field tagging system. Reputation gained in children is also gained in the parents. Authors tag their papers with any fields they feel are relevant.

This means authors can tag their papers with fields higher up the hierarchy to cast a wider review net, or go lower down the hierarchy to cast a narrower one. It also enables cross-discipline review and collaboration very easily - authors simply tag their papers with the fields of both disciplines.

The review interface combines aspects of Github PRs and Google docs.

Review is split into two phases: pre-publish "review" focused on giving authors constructive critical feedback to help the improve their work and post-publish "refereeing" which looks more like traditional peer review and is the primary mechanism through which new authors gain reputation.

The whole site is built around the idea that scholars are working to collectively build the body of human knowledge and make it the best they can.

You can see the production site here: https://peer-review.io

You're welcome to explore the staging site and treat it as a sandbox, if you'd like: https://staging.peer-review.io

It's open source: https://github.com/danielbingham/peerreview

I'm doing all the development in the open as much as possible. If it gains traction, the plan is to form a non-profit around it and explore whether a web platform can be governed democratically as a multi-stakeholder cooperative and if we can solve some of the issues around large centralized platforms through that governance approach.

I'm working open source and would welcome contributions! (https://github.com/danielbingham/peerreview)

(Although, the first contribution would probably need to be getting the local working again in a new context... I've been going fast and taking on some techdebt that will need to be paid down soon.)

Thanks for this article.

I want to combine the benefits of kernel threads with coroutines or goroutines/green threads/lightweight threads. (If anybody knows anything specifically about fibers, I'd appreciate that because I'm not familiar with them.)

I have a lightweight thread scheduler https://github.com/samsquire/preemptible-thread which is a 1:M:N scheduler (1 scheduler thread, M kernel threads, N lightweight threads) with the lightweight threads being multiplexed on the kernel threads.

I am working on a multithreaded architecture which I all 3 tier multithreaded architecture. It combines request parallelism with IO and CPU parallelism and intra request parallelism.

We split kernel threads into three groups: app threads, which run lightweight threads, IO threads (liburing/epoll) and traditional CPU threadpool with work stealing.

* The IO threads have buffers that other threads can write to to queue up data for sockets.

How would you do control flow and scheduling and parallelism and async efficiently with this code?

`db.save()`, `download()` are IO intensive whereas `document.query("a")` and `parse` is CPU intensive.

I think its work diagram looks like this: https://github.com/samsquire/dream-programming-language/blob...

I've tried to design a multithreaded architecture that is scalable which combines lightweight threads + thread pools for work + control threads for IO epoll or liburing loops:

Here's the high level diagram:

https://github.com/samsquire/ideas5/blob/main/NonblockingRun...

The secret is modelling control flow as a data flow problem and having a simple but efficient scheduler.

I wrote about schedulers here and binpacking work into time:

https://github.com/samsquire/ideas4#196-binpacking-work-into...

I also have a 1:M:N lightweight thread scheduler/multiplexer:

https://github.com/samsquire/preemptible-thread

* I want to keep IO and CPU in flight at all times.

I think I want this schedule:

https://user-images.githubusercontent.com/1983701/254083968-...

I have a toy 1:M:L 1 scheduler thread:M kernel threads:N lightweight threads lightweight scheduler in C, Rust and Java

https://github.com/samsquire/preemptible-thread

This lets me switch between tasks and preempt them from user space without assistance at descheduling time.

I have a simplistic async/await state machine thread pool in Java. My scheduling algorithm is very simple.

I want things like backpressure, circuit breakers, rate limiting, load shedding, rate adjustment, queuing.

Thanks for this article and to ingve for submitting it.

Concurrency and async is my favourite topic. I wrote a very simple toy lightweight 1:M:N (1 scheduler:M kernel threads:N lightweight threads) thread scheduler in C, Rust and Java.

https://github.com/samsquire/preemptible-thread

It works on the principle that hot loops can be interrupted BY ANOTHER THREAD (the scheduler thread) on a timer, to give lightweight threads a chance to execute.

What I think I want today though is an extremely rich process/concurrency API that resembles a stream API but for processes. For example, we should be able to create pipelines that can be paused, resumed, forked, merged, drop_while, iterate_until and whatever else would be useful.

I really like this.

Thank you for your comment and sharing.

I have a lightweight 1:M:N runtime (1 scheduler thread, M kernel threads, N lightweight threads) which preempts by setting hot loops to the limit.

https://github.com/samsquire/preemptible-thread (Rust, Java and C)

How do you preempt code that is running?

https://github.com/samsquire/ideas5/blob/main/NonblockingRun...

The design is that we have three groupings of thread types. The application starts up some application threads which are not associated with a request, these service multiconsumer multiproducer thread safe ringbuffers in lightweight threads with a Go-erlang-like lightweight process runtime. (My simple lightweight thread runtime is https://github.com/samsquire/preemptible-thread) We also multiplex multiple network clients sockets across a set number of kernel threads which I call control threads. Their responsibility is to dispatch work to a work stealing thread pool ASAP which has its own group of threads. So we pay a thread synchronization cost ONCE per IO which is the dispatch from the control thread to a thread pool thread. (Presumably this is fast, because the thread pool threads are all looping on a submission queue)

We split all IO and CPU tasks into two halves: submit and handle reply. I assume you can use liburing or epoll in the control threads. The same with CPU tasks and use ringbuffers to communicate between threads. We can always serve client's requests because we're never blocked on handling someone else's request. The control thread is always unblocked.

I think this article is good regarding Python's asyncio story:

I am deeply interested in the multithreading, parallelism, async and coroutine design space and I journal about it everyday in my ideas journal.

I wrote a toy very simple 1:M kernel threads:N lightweight thread runtime in terrible Rust, C and Java.

Hot loops use a structure for its limit and looping variable. Then to cancel the loop, you set the looping variable to the limit from a scheduling thread, cancelling the loop. This is used for process switching and scheduling but it can also be used for cancellation.

Can create very responsive code this way, it's even possible to cancel while (true) loops by replacing them with while (!preempted) {}.

https://github.com/samsquire/preemptible-thread

There is potential for a race, but that can be detected and worked around.

I also have a M:N m kernel threads to N lightweight thread userspace preemptive scheduler at https://github.com/samsquire/preemptible-thread It would be nice to schedule lightweight threads in a JIT compiler. Imagine being capable of running processes similar to BEAM and Go but with JIT.

This is interesting, thank you.

I really should learn from BEAM and the OTP and learn Erlang. I get the feeling it's super robust and reliable and low maintenance. I wrote a userspace multithreaded scheduler which distributes N lightweight threads to M kernel threads.

https://github.com/samsquire/preemptible-thread

I recently wrote a JIT compiler and got lazy compilation of machine code working and I'm nowhere near beginning optimisation

https://github.com/samsquire/compiler

How do you write robust software, that doesn't crash when something unexpected goes on?

I looked at sozo https://github.com/sozu-proxy/sozu

and I'm thinking how to create something that just stays up and running regardless.

I wrote a preemptive 1:M:N scheduler in C, Rust and Java.

https://github.com/samsquire/preemptible-thread

It is a 1:M:N scheduler where there is one scheduler thread, M kernel threads and N lightweight threads. I take advantage that loop indexes can be structures and can be modified by other threads. So we can set the thread's looping variable to the limit to end the current loop and pause it and then schedule another thread.