Albert Zeyer

> Anyway, the sorting might change in some cases if hash_overwrite is considered which breaks backwards compatibility. Yes it changes the behavior, but I'm not sure if this really would...

My suggestion in https://github.com/rwth-i6/sisyphus/issues/94 was actually to keep the behavior of `__lt__` and `__eq__` and `__hash__` just as before for the case without `hash_overwrite`. I just meant that with a...

> The creator is always assumed to be a Job and sis_id of a Job is set and computed internally by Sisyphus at construction time and assumed to be fixed....

I don't really know why we have `WAIT_PERIOD_JOB_FS_SYNC` and co. Apparently there was some issue before? My assumption was that the sync across nodes could be delayed? But I'm certain...

Do you have a suggestion how to implement the logic for `WAIT_PERIOD_JOB_FS_SYNC`? Basically the wait should only be skipped if it is *between* two jobs from the `LocalEngine`. In `Task.finished`,...

The scrambled output means that there are many processes here stopped at the same time by SIGINT.

Are you saying `GRAPH_WORKER=1` is anyway always better and we can remove the old code which handles `GRAPH_WORKER>1`? I'm not searching for workarounds. Also, I could simply just ignore this...

Hm ok I need to do some debugging, this seems to change the hash.

Ok, similar fix as in #89. Now for my simple test I get the same hash.

However, the speedup is much less now. Need to do some benchmarks. I think it should still be faster than before though.