Swifty <steve.j.swift@gmail.com> wrote:

>On Fri, 24 Feb 2012 17:25:42 +0000, Jeremy Nicoll - news posts
><jn.nntp.scrap007@wingsandbeaks.org.uk> wrote:
>
>>Except for the multiple simultaneous access issue. IIRC (having seen your
>>common routines code) you don't have your log write code do multiple
>>retries, nor have a fallback if none of those work.
>
>"Call stream log,'c','open write append'" and a simple:
>"call lineout log,date() time() text"
>
>... are all you need, at least in the Linux environment.

Is that because you're only writing a single line? If so it'd imply that
the writing of a line is an atomic process in the file system and possibly
the OS. I don't see why it should be though - I think I thought unix files
were just character streams.

What stops a line being written by one process from being mixed up with one
from another?


> Linux assumes that the programmer knows what they want, so there are no
> interlocks to prevent concurrent write from multiple processes.

So why did your testing never produce mixed-up output?


> But, like you, I was leery of problems. So I wrote a test program. You
> passed it an integer, N. It started N "threads". Each thread wrote 10,000
> lines to the log file, numbered 1-10,000.

Did those threads run under separate processes?

>When the threads had all ended, the main routine scanned the log file
>to ensure that it had N entries for every number from 1-10,000
>
>I ran it many times, with values of N from 1-100. It never failed. I
>was right to trust Linux to do what I wanted, and not what it thought
>should happen. :-)

But why? I would wan to understand why output hadn't been mixed up; that
it hadn't suggests to me that the test was in some way inadequate.

>As it happens, I do also check the results of OPEN and LINEOUT, and
>log failures in the common "Things you need to worry about" log (yes,
>another of those global log files I'm so enamoured of).

If the OS doesn't protect the file, I'm not sure that testing the return
code from a lineout would tell you anything. A lineout would have caused a
number of characters to be sent to a file ok. But if something else is also
sending chars to the file that wouldn't affect lineout.

>Of course, it's conceivable that there is an error in the "Things you
>need to worry about" log code, but this is getting recursive.


--
Jeremy C B Nicoll - my opinions are my own.

Email sent to my from-address will be deleted. Instead, please reply
to newsreplyaaa@wingsandbeaks.org.uk replacing "aaa" by "284".