| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
Also, if you just have two rust packages, this will like spin continuously with the second package? Seems a bit tricky to make it behave reasonably. But maybe it just doesn't matter? |
Sorry, something went wrong.
Yes, one thread will keep pushing and popping the second package from queue until the first one finishes. I hope it doesn't matter, but when we find it matters, I guess we can add an additional lock for rust packages or incrementally increase the sleep time. |
Sorry, something went wrong.
|
Maybe add a comment indicating that this is what happens when only rust classes are left and we don't exactly love it. Also let's increase the wait time to 50 or 100 ms. |
Sorry, something went wrong.
Sounds good. Done. |
Sorry, something went wrong.
Co-authored-by: Hood Chatham <roberthoodchatham@gmail.com>
|
Thanks for the review! |
Sorry, something went wrong.
Co-authored-by: Hood Chatham <roberthoodchatham@gmail.com>
| build_queue.put((job_priority(pkg), pkg)) | ||
|
|
||
| # Release the GIL so new packages get queued | ||
| sleep(0.1) |
There was a problem hiding this comment.
Maybe we could try releasing the lock before performing this sleep? Since Python threads are somewhere between threads and coroutines and the only yield point is when the lock is held this may have something to do with the problem. Maybe also put one or more unconditional sleep(0) with the lock unacquired.
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Description
Resolve #3565
Checklists