Hacker News new | past | comments | ask | show | jobs | submit login

Using globals is simpler, it's also pretty natural in event driven architectures. Passing everything via function arguments is welcome for library code, but there's little point to using it in application code. It just complicates things.



The problems it causes for Postgres are outlined in the article on LWN.


> Globals work well enough when each server process has its own set...

PostgreSQL uses a process model. So the article just states that globals work fine for PostgreSQL

> Knizhnik has already done a threads port of PostgreSQL. The global-variable problem, he said, was not that difficult.

I see no big problem based on information from person who did some porting already.


Knizhnik made these variables thread local, which is fine if you have a fixed association of threads to data. This looses some flexibility if your runtime needs to incorporate multiple sessions on one thread (for example to hide IO latency) in the future. In the end, the best solution is to associate the data that belongs to a session with the session itself, making it independent on which thread it's running on. This is described by Knizhnik as "cumbersome", which is exactly why people should have not started with global variables in the first place. (No blame, Postgres is from 1986 and times were very different back then).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: