haiku
sweb
| haiku | sweb | |
|---|---|---|
| 11 | 1 | |
| 1,765 | 114 | |
| 0.7% | 0.0% | |
| 9.8 | 4.3 | |
| 5 days ago | 12 days ago | |
| C++ | C++ | |
| GNU General Public License v3.0 or later | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
haiku
-
Haiku's (Kernel) Condition Variables API: Design and Implementation
Haiku uses the System V ABI (mostly.) So, we're doing the same things Linux and the BSDs are here, simply by using GCC or Clang without any special tuning here.
> I reckon that before trying to claim you've innovated here it might be a good sense check to compare baseline.
The baseline is "what are other operating systems' kernel- and userland-level condition variables APIs?" And none of the ones I looked at had anything like what Haiku has here, they all have something which is the more classical "lock-switched condvars" just like POSIX has.
The API itself does not depend on what memory ordering semantics are any more than a "mutex_lock()" API does. The implementation will be somewhat contingent on it, of course, but those are two separate matters.
> What exactly are the Haiku atomic operations, in terms of the C++ 11 Memory Model?
The atomic_() functions are (on most architectures, x86 included) implemented using GCC/Clang's __atomic_* functions, with various __ATOMIC_* orderings chosen as appropriate. You can see them defined in the system header here: https://github.com/haiku/haiku/blob/master/headers/os/suppor...
> because you're innovating before 2011, you're inventing the model
No, not really? GCC has had atomic builtins since at least 4.1.0 in 2006. The documentation (https://gcc.gnu.org/onlinedocs/gcc-4.1.0/gcc/Atomic-Builtins...) says: "In most cases, these builtins are considered a full barrier. That is, no memory operand will be moved across the operation, either forward or backward." -- which is basically equivalent to today's __ATOMIC_SEQ_CST.
> so Haiku is off in the jungle on its own and everybody else has a map now, figure out where you are on that map first.
We already did that years ago. The atomic_() functions linked above in SupportDefs.h have been implemented using the C++11-standard GCC builtins since 2014, and the older __sync_ builtins for years before that.
Anyway, the algorithm described in this article, even if Haiku's atomic functions were not 1:1 with C++11-standard definitions (which they are, as noted above), is clearly portable to other OS kernels. So I am not sure what basis your comment has, regardless.
-
Problems while building haiku from source
I'm currently trying to build Haiku from source (following https://github.com/haiku/haiku/blob/master/ReadMe.Compiling.md), but I'm getting errors while building with "jam -q -j12 @nightly-anyboot".
- Haiku R1/beta4 has been released
-
HaikuOS Device Driver References
Something like this? https://github.com/haiku/haiku/tree/master/src/add-ons/accelerants/radeon
- Haiku Beta4 Release Near?
- How to programmatically find out if computer is on
sweb
-
Will we ever need 128 bit computers for gaming?
If you're interested, that's the code of the framework: https://github.com/IAIK/sweb
What are some alternatives?
serenity - The Serenity Operating System 🐞
Lemon-OS - The Lemon Operating System
morphiOS - A lightweight 32-bit operating system written in C++ for the i386 (x86) architecture.
skift - 🥑 The delightful operating system.
Simply-Love-SM5 - a StepMania 5 theme for the post-ITG community
IncludeOS - A minimal, resource efficient unikernel for cloud services
Quaternion - A Qt-based IM client for Matrix
managarm - Pragmatic microkernel-based OS with fully asynchronous I/O
WonderBrush-v2 - Last known version of the code to WonderBrush (as included in Haiku)