Skip to content

blocked playground links #1111

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
oconnor663 opened this issue Oct 17, 2024 · 2 comments
Closed

blocked playground links #1111

oconnor663 opened this issue Oct 17, 2024 · 2 comments

Comments

@oconnor663
Copy link

oconnor663 commented Oct 17, 2024

This might not be the best fit for a GitHub issue, but I'm not sure where else to report it. I've been working on an article that uses a large number of Playgroud examples (rough draft), and I've noticed that some of my Playground links are blocked. A block looks like this:

Image

I suspect I earned the original block because one of my examples burns a 2-3 seconds of CPU time, and I'll admit to abusing 5-10 minutes of total Playground CPU time while I was developing it. (I am ashamed of my crimes.) Here's a short link to an offending, CPU-burning example. It's interesting that the example is accessible through that short link, but blocked when I embed the source in the link, as I do for most links in the article. (I auto-generate them from checked-in code files.) Here's another short link to an example that burns 1 second of CPU, and the source-embedded version which is blocked.

I suppose I should start by asking whether the Playground Powers That Be feel that these examples have enough educational value to justify the CPU the consume. (In short, they're demonstrating the busy loop that you create when you implement async IO without an underlying blocking API like libc::select or libc::poll.) If not, I'll delete them or host them some other way. But if so, what are my options for getting them unblocked, and how can I make sure they don't get blocked again over time? Thanks a million for your help either way.

Edit: Ooo this is issue number 1111, neat.

Edit: For searchability, the error text in the screenshot is 413 ERROR The request could not be satisfied..

@shepmaster
Copy link
Member

It's interesting that the example is accessible through that short link, but blocked when I embed the source in the link,

HTTP GET requests generally have a limit on their length. I don't know if it's CloudFront, nginx, or Axum, (my guess is CloudFront) but one of those is rejecting it because that URL is too big (over 10KiB).

@oconnor663
Copy link
Author

Oh wow, I was just making all that up about CPU usage. (I mean, I will try to be judicious about abusing CPU time either way.) I guess there was some loose correlation between the length of the code file and how much CPU it was using, and my lizard brain just latched onto that...

Out of curiosity, do you have any suggestions for autogenerating playground links for files in the 10K-20K size range? It looks like I can make my own Gist and link to that ID, but I'm curious whether I'm missing any other good options. Thanks for your help!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants