Exclude threads from receiving jobs

[ghost]

Hello, Rich! :)

I was just wondering is there a way to tell sewing I don't want a particular thread to ever receive a job?

Thanks!

[ghost]

Mainly the one that launches main_procedure and schedules jobs. I need sew_stitches_and_wait and sew_wait to just sleep or loop forever waiting jobs on other threads to finish.

[ghost]

Looking at internals I guess Sewing struct carries threads? Would be cool if I could then just:

void main_procedure(struct Sewing * sewing, Sew_Thread * threads, size_t thread_count, void * args) {
  sew_exclude_thread(sewing, sew_thread_current());
  ...
}

Or something like that...

[JodiTheTigger]

Ok, If I understand your question, you want a thread that never does a job.

If that's the case, just manually make a new thread outside the sewing system and use that.

However if you want to make it so that a certain job is never run on a particular thread then the current API doesn't support what you're asking for :-(

How I would do it would be to modify Sew_Stitch and add an size_t ignore_mask; option. This is a bit flag, where each bit set in the mask means that that thread will not run that Sew_Stitch.

Then I would put in a mask check in sew_get_next_fiber to ignore a job if the current thread and the ignore mask match.

I'll leave this open as a feature request for a new version (assuming you meant explanation 2, and not the explanation 1)

[ghost]

If that's the case, just manually make a new thread outside the sewing system and use that.

Yea, but I wanted to use that thread for job submission...

However if you want to make it so that a certain job is never run on a particular thread then the current API doesn't support what you're asking for :-(

No problem! I temporarily switched to Micha's sched.h, and although you can't make a thread never receive jobs and only submit too, it works for my OpenGL code which for some reason didn't liked sewing jobs on the thread that also called GL API, GL would not block on glClear resulting in ~4 ms frames and constant vsync misses resulted in massive stalls... Yeah, the whole thing was weird, maybe it's sensitive to some thread stack values, dunno.

[JodiTheTigger]

That GL problem you're having sounds an awful like #14, and this saddens me.

If you could post a minimal viable program showing the GL problem, I can definitely investigate it (maybe even fix it).

The way I would schedule threads from a non-fiber thread would be via a lockless queue, where there is a fiber job who's sole job is check the queue, and re-queue the job into the fiber system when it gets one.

But, if I fix your original problem, then this shouldn't be a required feature in the first place.

[JodiTheTigger]

Oh, also, I know that GL drivers really don't like you submitting GL calls from a thread that's separate from the one use to create the context. Dunno if that's changed with the more recent 4.x stuff, but I know old openGL hated it.

[Leandros]

I believe the best way to fix this, is to not allow the mainthread to execute jobs. If the main thread is waiting on jobs to be finished, it'll just wait (or spin) on a latch. By doing this, you ensure that the main thread is always easily identifiable as the main thread, and can than be used for OpenGL / system calls. You could even go as far as making the main thread another job system, as suggested.

This is also approach which I've taken, and have seen no issues so far.