Is this how news.ycombinator.com runs? (Ctrl+F for "Closures Simulate Subroutines")
1–10 of 23 posts
Re: Is this how news.ycombinator.com runs? (Ctrl+F for "Closures Simulate Subroutines")
#2I always assumed it was, and that the closures are stored in the user's session (in memory, on the server). You notice that if you leave a comment reply box up on the screen long enough, you'll get "Unknown or expired session" when you try to submit, and have to back up to the main comment page before you can try again?
Re: Is this how news.ycombinator.com runs? (Ctrl+F for "Closures Simulate Subroutines")
#3I always assumed it was, and that the closures are stored in the user's session (in memory, on the server). You notice that if you leave a comment reply box up on the screen long enough, you'll get "Unknown or expired session" when you try to submit, and have to back up to the main comment page before you can try again?
If they expire sessions in order to avoid losing memory over users leaving without ever calling the closure, their timer seems short for what it gains.
The link name "fnid=" is a pretty strong giveaway as to what is underneath.
Re: Is this how news.ycombinator.com runs? (Ctrl+F for "Closures Simulate Subroutines")
#4I always assumed it was, and that the closures are stored in the user's session (in memory, on the server). You notice that if you leave a comment reply box up on the screen long enough, you'll get "Unknown or expired session" when you try to submit, and have to back up to the main comment page before you can try again?
[silly test to see if they remove the closure from the HT once it's used, and the answer seems no]
Re: Is this how news.ycombinator.com runs? (Ctrl+F for "Closures Simulate Subroutines")
#5I always assumed it was, and that the closures are stored in the user's session (in memory, on the server). You notice that if you leave a comment reply box up on the screen long enough, you'll get "Unknown or expired session" when you try to submit, and have to back up to the main comment page before you can try again?
If they expire sessions in order to avoid losing memory over users leaving without ever calling the closure, their timer seems short for what it gains. The link name "fnid=" is a pretty strong giveaway as to what is underneath.
Yes, I find it too short and the end result is annoying but passable for the audience here. Non-technical users wouldn't be so understanding I suspect.
How are hash keys deleted? Age? Or are just the last N generated ones kept?
Re: Is this how news.ycombinator.com runs? (Ctrl+F for "Closures Simulate Subroutines")
#6I always assumed it was, and that the closures are stored in the user's session (in memory, on the server). You notice that if you leave a comment reply box up on the screen long enough, you'll get "Unknown or expired session" when you try to submit, and have to back up to the main comment page before you can try again?
For calls that don't need to know about more state than their arguments, we just use an ordinary url with arguments. Otherwise we make a closure and store it in a hash table in memory, and make the url be x?fnid= where the argument is the hash key. When an http request comes in, we call the corresponding closure. Sometimes what to do next after following a link generated by the closure (e.g. what to do after logging in when you're not logged in and you submit a link through the bookmarklet) is part of the state of the closure; in that case it's a bit like a continuation.
We keep only the most recently generated 20,000 closures. When you click on a link that says it has expired, that means either it has been purged from the closure table, or that we've restarted the server.
Re: Is this how news.ycombinator.com runs? (Ctrl+F for "Closures Simulate Subroutines")
#7I always assumed it was, and that the closures are stored in the user's session (in memory, on the server). You notice that if you leave a comment reply box up on the screen long enough, you'll get "Unknown or expired session" when you try to submit, and have to back up to the main comment page before you can try again?
For calls that don't need to know about more state than their arguments, we just use an ordinary url with arguments. Otherwise we make a closure and store it in a hash table in memory, and make the url be x?fnid= where the argument is the hash key. When an http request comes in, we call the corresponding closure. Sometimes what to do next after following a link generated by the closure (e.g. what to do after logging…
Isn't there a risk, that someone can (accidentally or not) enter hash-code of someone else's "closure"?
Re: Is this how news.ycombinator.com runs? (Ctrl+F for "Closures Simulate Subroutines")
#8I always assumed it was, and that the closures are stored in the user's session (in memory, on the server). You notice that if you leave a comment reply box up on the screen long enough, you'll get "Unknown or expired session" when you try to submit, and have to back up to the main comment page before you can try again?
For calls that don't need to know about more state than their arguments, we just use an ordinary url with arguments. Otherwise we make a closure and store it in a hash table in memory, and make the url be x?fnid= where the argument is the hash key. When an http request comes in, we call the corresponding closure. Sometimes what to do next after following a link generated by the closure (e.g. what to do after logging…
Isn't there a risk, that someone can (accidentally or not) enter hash-code of someone else's "closure"?
Re: Is this how news.ycombinator.com runs? (Ctrl+F for "Closures Simulate Subroutines")
#9Earlier quoted context omitted.
For calls that don't need to know about more state than their arguments, we just use an ordinary url with arguments. Otherwise we make a closure and store it in a hash table in memory, and make the url be x?fnid= where the argument is the hash key. When an http request comes in, we call the corresponding closure. Sometimes what to do next after following a link generated by the closure (e.g. what to do after logging…
Isn't there a risk, that someone can (accidentally or not) enter hash-code of someone else's "closure"?
One could avoid that problem by keeping track of the owner of each closure and ensuring the user is properly authenticated before calling the closure.
Re: Is this how news.ycombinator.com runs? (Ctrl+F for "Closures Simulate Subroutines")
#10Earlier quoted context omitted.
For calls that don't need to know about more state than their arguments, we just use an ordinary url with arguments. Otherwise we make a closure and store it in a hash table in memory, and make the url be x?fnid= where the argument is the hash key. When an http request comes in, we call the corresponding closure. Sometimes what to do next after following a link generated by the closure (e.g. what to do after logging…
Isn't there a risk, that someone can (accidentally or not) enter hash-code of someone else's "closure"?
The code explicitly protects against that.