Re: [dylan] Stream locking (was: Method combinations as a design pattern for locking)
Hannes Mehnert <[email protected]> Wed, 18 Dec 2013 13:24:04 +0100
| Newsgroups | gmane.comp.lang.dylan.gwydion.devel |
|---|---|
| Message-ID | <[email protected]> |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA384 Hi, there's a thread from the beginning of this year on the same topic. Not sure why this is brought up so often. In that discussion, I appreciate Bruce Hoult's comment: > I think that, except in a very few cases such as stderr, multiple threads > writing to the same stream is at the least bad program design and probably > a bug. > I would make the default to be non-locked, but with detection and warning > of writing from multiple threads, if cheap to do. e.g. store and > compare the thread IDs or TLS pointers or something. Even the stack > pointer would > suffice, if you can get the stack base and limit for the current > thread (only has to be one once per non-locking stream, the first > time it's used). And while I'm happy with the current code, having to explicitly annotate streams which do not require a lock, I'd be ok to remove these by-default locks if there is a warning implemented as Bruce proposes above. On 12/18/2013 02:59, Bruce Mitchener wrote: > Unfortunately, a couple of years ago, some locks were introduced to > the streams library and I suspect that that has led to some issues > over time. An example of that is that in the typical case of > creating a <string-stream> for printing some data to it, we have to > be sure that we create it unlocked (like in the date code in the > system library), otherwise it can become a visible overhead when > profiling. I consider these stream locks to be easy catches during profiling. I also do not understand why you want to remove (in your branch) both the init-value for the private-stream-lock-value slot of <basic-stream>, as well as the calls to with-stream-locked from within io? Does the test whether stream-lock is non-false (in lock-stream) lower the performance in a significant way? Aren't there more serious performance bottlenecks in the streams library? Just my 2 cents, Hannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBCQAGBQJSsZPkAAoJELyJZYjffCjuD1YQAL1B5ec8VsWmokHLRpBFN1nP OiyHlYoZFxS5auFWNNBcxTDTrGwPmNcvOIm1O9utAEk1D3x/oIHcnvL56c+3axjt gfyn2uMBWHNZDzEYqQtZDTjp+mBXNCqCnns23yUU73hwgyqPCJybgygxrtODBd7D EUF4L3rDM33+XetdczPCMLbc4E70egOBP1y86S/pHfyeICZWw00O/eMkSscZeJWP h8/f+vp1vjiIQ7kkZ4YcByDqrUbH7U9OOxyFlFrpune3C8MD+W9cxZGXeEPZ4AuI fgVhqvksaklk0jeOaiVjvzQFylmkJ/zkKFcIIdn8dQBgrUgxRQtQ7vfsHjIAYt+3 g/dnQ8WNCYNRwyzVuwtKhYn105TAGH6X5F3ZHJO+6tfYzq5bbQWdQy6iPxvb1NuG BHTqGgx7/eSYIViegvdSPi7MY4M561cCOiI3aeN94moo/sFnlpnHmk/w2j49+L+H 361ZDzUlQXJ3mIP19goQC/oT9onP1YQygYlcrssCi5eJUIt2EkNHtZUOKUUfeuO/ 4cCCVWVVmnGgg8ucKuniDztxU/0m3yqS+n0+wfeYPFgyjajTVACAXpZKS6wfqlN9 HekQSKLSfJq9bNt3lTIaMx3sJlLbLlGhX3SXnwEOsbZu/qeGFLRp3XCxuPk47Krs yZEre1qno1eIhrf0Laxj =kR6O -----END PGP SIGNATURE----- _______________________________________________ hackers mailing list [email protected] https://lists.opendylan.org/mailman/listinfo/hackers