What Are You Building? Share Your Projects

I am building a site where people can ask for feedback on how they did in their interviews. I plan to extend it to all sorts of code reviews and/or interview feedback.

https://www.interviewblindspots.com/featured

People will post the question and the code they wrote in interviews. Experienced developers will give feedback.

Contributors/Cofounders welcome

Sounds interesting! Do you already have a website for this project?

but... it's just a youtube wrapper, what's the goal?

I had need for a special purpose lock that solved this problem: There are `N` task sharing a single resource. It is incorrect for the `n`th task to acquire a lock on it until after the `n - 1`th task has released its lock. When the `N - 1`th task releases its lock the `0`th task may acquire the lock again.

I couldn't find any lock off the shelf that solved this, or a clean way to hack it with a fair mutex. So I wrote my own, and I'm pretty sure it's correct (1).

It's like a ticket lock, except the total number of tickets is known up front so every task can get one ticket. To acquire a lock is one CAS, where the lock is acquired iff the "current" value of the lock matches the ticket value of the task, if so we swap in a magic LOCK value. When the writer releases the lock it writes (ticket + 1) % num_tickets back to current so the lock can be acquired by the next task.

There's a deadlock condition though - if one task is cancelled while any other task is outstanding, no other task may acquire the lock, even if the cancelled task didn't acquire it!

To deal with that, the lock is poisoned with a magic POISON value. Then when any other task attempts to acquire the lock, but its value is POISON, then an error is returned and those tasks may be cancelled accordingly.

It's be possible to support adding/removing tasks concurrently by replacing the tickets with a circularly linked list of atomic pointers, so when one task is cancelled the "next" of the "prev" item can be atomically swapped, but I don't have a use case for that and it's annoying enough to write in Rust that I didn't want to bother with it.

(1) The code for this is here: https://github.com/m-hilgendorf/sequex/. I call it "sequex" for sequence-mutex. It could also be called a round-robin lock or something like that.

---

You could do this with just a ticket lock, where you take a ticket up front N times and then give one ticket to each task. When a task's ticket comes up it acquires the lock, but before releasing the lock, it takes another ticket. That's where I started, but I found this implementation cleaner.

I'm working on a personal hobby project of mine, written in MOO [0] of all things. Its a bridge to homeassistant - it connects to your local instance and lets you observe and control anything you have set up in homeassistant from within the MOO - toggle lights, set thermostats, send tts alerts, etc. It also receives state change events, so you can have objects that act like their real counterparts and display up-to-date information as long as the bridge is online. I run a local house MOO for my roomates and myself, and I thought it would be fun to control my smart home from it. Challenges... The first was reading the web socket rfc and writing my own implementation, in what is probably considered an esoteric language at this point. Next was discovering just how much of home assistant's web socket API is undocumented (read: pretty much all of it). There's a page which mentions a handful of APIs, and this got me started, but I really had to start reading homeassistant's code to see what other commands were available and being used presumably by the front-end to do some of what I wanted (listing users, subscribing to state updates for specific entities, listing areas, devices, etc)

[0] https://en.wikipedia.org/wiki/MOO