Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please reconsider creating separate projects for mutexed classes #1

Open
yurivict opened this issue Feb 4, 2019 · 3 comments
Open

Comments

@yurivict
Copy link

yurivict commented Feb 4, 2019

I'm hesitant to create a package for locked_sstream, because following the same logic any STL class can be mutexed and packaged the same way. This would create a lot of packaging overhead for no good reason.

@cth103
Copy link
Owner

cth103 commented Feb 4, 2019

Hi, I think sstream is a slightly special case, as there is a bizarre bug on Mac OS X where using two different stringstream objects simultaneously in two different threads can crash.

That being said, with hindsight I'm not sure that this library is the best solution, nor that it is a complete fix, so it may be possible to make it go away.

Are you packaging DCP-o-matic for FreeBSD?

@yurivict
Copy link
Author

yurivict commented Feb 4, 2019

Are you packaging DCP-o-matic for FreeBSD?

yes

@cth103
Copy link
Owner

cth103 commented Feb 9, 2019

Great! I think this library can be removed, but I will need to wait a few weeks as I'm shortly to make a beta release. At the very least it can be made OSX only.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants