*rewrites rust mpsc*

you did it wroooong

I thought my threads were locking if I had thousands of jobs spawning thousands of more jobs. turns out it's fine. actually if I organize my data locks in the way everyone wants to do them my CPU fans go off but my original way you don't feel jack shit and processes faster

turns out it's because 320k jobs is a bit much for mpsc. because my jobs can spawn more jobs the whole thing just grinds to a halt. and there's sync-mpsc which allows you to have a maximum number of data you send through it, therefore I can just have 245 sent jobs instead of 320k but then this locks all the threads because for a thread to finish it needs to finish sending jobs, but a sync mpsc won't let you send a job if current jobs are over the specified limit. so all the threads get stuck sending jobs. smart. not. what's even the point of that?!

and evidently there's no built-in way to prioritize certain jobs. the AI thinks you should just send jobs in and each thread should have a priority queue. I don't know sounds dumb to me. then you could by random luck have threads with lots of jobs that need to be prioritized to be done and other threads stuck hanging waiting for previous jobs / the other threads. no thanks

so clearly the solution is to rewrite mpsc but allow prioritization when a thread goes in to ask for a job to do

since my jobs are intended to start other jobs, it makes sense to have no actual upper bound limit to the number of jobs in the queue but to favour doing jobs that won't start new jobs to lower the RAM and compute necessary to juggle all this

hope this is the actual problem. cuz the code works for like 200 jobs spawning 500 jobs each, which is 100k jobs total
but it stalls to a halt doing 8300 jobs spawning 500 jobs each (which if I do the math -- in my tests it stalls at 320k jobs and seems the number should be 4,150,00 jobs -- yeah I think this is probably the damned problem)