Some comments
Duy Nguyen
(09 Sep 2020 11:38 UTC)
|
||
Re: Some comments
hga@xxxxxx
(09 Sep 2020 13:14 UTC)
|
||
Re: Some comments
Duy Nguyen
(09 Sep 2020 14:06 UTC)
|
||
Re: Some comments
John Cowan
(10 Sep 2020 02:05 UTC)
|
||
Re: Some comments
hga@xxxxxx
(10 Sep 2020 03:06 UTC)
|
||
Re: Some comments
hga@xxxxxx
(10 Sep 2020 03:21 UTC)
|
||
Re: Some comments
John Cowan
(10 Sep 2020 03:55 UTC)
|
||
Re: Some comments
Duy Nguyen
(10 Sep 2020 09:17 UTC)
|
||
Re: Some comments
hga@xxxxxx
(10 Sep 2020 14:43 UTC)
|
||
Re: Some comments
Duy Nguyen
(10 Sep 2020 15:35 UTC)
|
||
Re: Some comments
hga@xxxxxx
(10 Sep 2020 14:26 UTC)
|
||
Re: Some comments
John Cowan
(10 Sep 2020 15:39 UTC)
|
||
Re: Some comments Duy Nguyen (10 Sep 2020 09:29 UTC)
|
||
Re: Some comments
Alex Shinn
(10 Sep 2020 13:01 UTC)
|
||
(missing)
|
||
Fwd: Some comments
John Cowan
(10 Sep 2020 16:25 UTC)
|
||
Re: Fwd: Some comments
hga@xxxxxx
(10 Sep 2020 18:16 UTC)
|
||
Re: Fwd: Some comments
John Cowan
(10 Sep 2020 18:21 UTC)
|
On Thu, Sep 10, 2020 at 9:05 AM John Cowan <xxxxxx@ccil.org> wrote: > This being so, a function that is thread-safe in the sense of Posix threads may be completely unsafe in the sense of user-visible threads. Here's my new wording: > > <p>A Scheme implementation that supports both this SRFI and multiple > threads of control must ensure that when a thread invokes a blocking > procedure such as an R[4567]RS I/O operation, only that thread is > blocked and not any other concurrently running ones. Because > user-visible threads may be multiplexed on a single P<small>OSIX</small> > thread, be in a 1:1 relationship with P<small>OSIX</small> threads, > or run on different P<small>OSIX</small> threads at different times > in its lifecycle, there can be no guarantees that a P<small>OSIX</small> > function which is MT-Safe (that is, thread-safe in the sense of > P<small>OSIX</small> threads) is safe for user-visible threads. Thanks for the mention of MT-safe. >> I have an uneasy feeling about call-with-temporary-filename treating >> _any_ exception as "file exists". Unrelated (and unexpected) errors >> could also raise an exception and be misinterpteted as "file exist". > > > It doesn't matter why it fails exactly: it is never dangerous to try the next name. Admittedly, you may get an infinite loop if the prefix refers to a non-existent directory or something. Still, I'm not too worried about it. Imagine this. When I write the maker procedure, my fat fingers accidentally write "cat" instead of "car". In some schemes this will be a runtime exception. And because of this catch-all behavior, instead of having a nice and clear exception in my face so I can fix it, the code will just assume "file exists" and try out a couple more names. Eventually yes it may fail too, but that's way harder to trace back to the "cat" typo. > I'm reluctant to change it just before finalization. This is likely not your intention. But when I first read this the impression I had was "this is final, the final call is just formality, don't any of you dare make any comments!" -- Duy