Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> That one person that creates threads haphazardly will wreak havoc

What if someone comes along and starts adding threads and doesn't check what they are accessing? And doesn't read the documented invariants of the design?

Well I don't think any project can succeed if that's the level disorganization.

Are there certain kinds of bugs that are easy to regress last minute? Yes. A brand new thread without limited state is not one of them.

> put the onus of program soundness on the contributors to a program.

Who then is responsible for making sure the program is correct?



> Who then is responsible for making sure the program is correct?

I’d say this is mostly a function of the language or framework.

After that, it’s up to the tech leads to provide access patterns/examples that align with the needs of a particular project.

My point is not so much that you shouldn’t ever think about the implications of your code, just that contributors are humans and any project with enough contributors will have a mix of contributors with different knowledge, experience and skill sets. If you are leading one of those, it would behoove you to make doing the right thing easy for later contributors.


> I’d say this is mostly a function of the language or framework.

frameworks cannot ensure your program does what it's supposed to. People are responsible, not tools.

> contributors are humans

Yes - which is why I would discourage haphazard thread usage, and document existing thread architecture.

That's safer than "hey I threw on a mutex because who knows where this is accessed from".




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: