Readit NewsDead Comment
Dead Comment
diek commented on My Experience of building Bytebeat player in Zig blog.karanjanthe.me/posts... · Posted by u/KMJ-007
From the description I thought the expression was a function of only 't', and there was no (for instance) accumulation of the previously computed byte. Then in the image I saw the same value of 't' evaluating to different values:
t=1000: 168 t=1000: 80
Reading the source: https://github.com/KMJ-007/zigbeat/blob/main/src/evaluator.z...
It does look like the expression is a pure function of 't', so I can only assume that's a typo.
diek commented on The future of Python web services looks GIL-free blog.baro.dev/p/the-futur... · Posted by u/gi0baro-dev
Even with volatile it’s a load and then a store no? It may not be undefined behaviour, but I don’t think it will be atomic.
You're correct. If you have:
public int someField;
public void inc() {
someField += 1;
}
GETFIELD [someField]
ICONST_1
IADD
PUTFIELD [somefield]
They've literally never made a budget sedan EV. Looks like they are happy to let Hyundai and Tesla take that market, while they churn out SUVs?
Also the 35k trim won't be available until later this year.
They made the Bolt EV from 2016-2023, and they're revamping it to use the new Ultium platform.
You could buy a 2023 Bolt starting at $26,500, and they're great cars.
Using the INSERT/UPDATES is kind of limiting for your events. Usually you will want richer event (higher level information) than the raw structure of a single table. Use this feature very sparingly. Keep in mind that LISTEN should also ONLY be used to reduce the active polling, it is not a failsafe delivery system, and you will not get notified of things that happened while you were gone.
For my use cases the aim is really to not deal with events, but deal with the rows in the tables themselves.
Say you have a `thing` table, and backend workers that know how to process a `thing` in status 'new', put it in status 'pending' while it's being worked on, and when it's done put it in status 'active'.
The only thing the backend needs to know is "thing id:7 is now in status:'new'", and it knows what to do from there.
The way I generally build the backends, the first thing they do is LISTEN to the relevant channels they care about, then they can query/build whatever understanding they need for the current state. If the connection drops for whatever reason, you have to start from scratch with the new connection (LISTEN, rebuild state, etc).
> * use LISTEN to be notified of rows that have changed that the backend needs to take action on (so you're not actively polling for new work)
> * use NOTIFY from a trigger so all you need to do is INSERT/UPDATE a table to send an event to listeners
Could you explain how that is better than just setting up Event Notifications inside a trigger in SQL Server? Or for that matter just using the Event Notifications system as a queue.
https://learn.microsoft.com/en-us/sql/relational-databases/s...
> * you can select using SKIP LOCKED (as the article points out)
SQL Server can do that as well, using the READPAST table hint.
https://learn.microsoft.com/en-us/sql/t-sql/queries/hints-tr...
> * you can use partial indexes to efficiently select rows in a particular state
SQL Server has filtered indexes, are those not the same?
https://learn.microsoft.com/en-us/sql/relational-databases/i...
Admittedly I used SQL Server pretty heavily in the mid-to-late-2000s but haven't kept up with it in recent years so my dig may have been a little unfair.
Agree on READPAST being similar to SKIP_LOCKED, and filtered indexes are equivalent to partial indexes (I remember filtered indexes being in SQL Server 2008 when I used it).
Reading through the docs on Event Notifications they seem to be a little heavier and have different deliver semantics. Correct me if I'm wrong, but Event Notifications seem to be more similar to a consumable queue (where a consumer calling RECEIVE removes events in the queue), whereas LISTEN/NOTIFY is more pubsub, where every client LISTENing to a channel gets every NOTIFY message.
Thanks for the comprehensive reply, does the following argument stand up at all? (Going on the assumption that LISTEN is one more concept and one less concept is a good thing).
If I have say 50 workers polling the db, either it’s quiet and there's no tasks to do - in which case I don't particularly care about the polling load. Or, it's busy and when they query for work, there's always a task ready to process - in this case the LISTEN is constantly pinging, which is equivalent to constantly polling and finding work.
Regardless, is there a resource (blog or otherwise) you'd reccomend for integrating LISTEN with the backend?
In a large application you may have dozens of tables that different backends may be operating on. Each worker pool polling on tables it may be interested on every couple seconds can add up, and it's really not necessary.
Another factor is polling frequency and processing latency. All things equal, the delay from when a new task lands in a table to the time a backend is working on it should be as small as possible. Single digit milliseconds, ideally.
A NOTIFY event is sent from the server-side as the transaction commits, and you can have a thread blocking waiting on that message to process it as soon as it arrives on the worker side.
So with NOTIFY you reduce polling load and also reduce latency. The only time you need to actually query for tasks is to take over any expired leases, and since there is a 'lease_expire' column you know when that's going to happen so you don't have to continually check in.
As far as documentation, I got a simple java LISTEN/NOTIFY implementation working initially (2013?-ish) just from the excellent postgres docs: https://www.postgresql.org/docs/current/sql-notify.html
I've TFed and CAed for SSC fellows eons ago and the fact is UMich (especially the International Institute [0]), VT (CETS [1] and CGIT [2]), ASU (GSI [3] and CAPS [4]), and UNC (ASC [5], ISA [6], CES [7], and TISS [8]) remain great programs and tend to be fairly liberal.
Surprised TAMU wasn't included.
Edit: can't reply
> and lo and behold
Yep, but everyone who's an SSC will self-select for Mich, UNC, ASU, and VT. SSC fellows are smart and are gunning for top exit opps in the public and private sector. Hillsdale, Regent, and Liberty don't offer that and would limit career options as they are deeply ideological programs.
[0] - https://ii.umich.edu/ii/about-us/centers-programs.html
[1] - https://liberalarts.vt.edu/research-centers/ceuts.html
[2] - https://www.cgit.vt.edu/index.html
[3] - https://nationalsecurity.asu.edu/
[4] - https://www.capsresearch.org/
[5] - https://africa.unc.edu/
[6] - http://isa.unc.edu/
[7] - https://europe.unc.edu/
[8] - https://tiss-nc.org/