[M3devel] proposal for dealing with lazy console--please review and comment!
rodney.bates
rodney.bates at wichita.edu
Wed Jun 18 16:36:59 CEST 2008
I don't understand well enough what it means for a console
to be lazily-allocated, but I wonder if it makes any sense to
allow client code, by assignments to Stdio.stdout_Islazy, to
change this property in general. Why would a FileWr.T ever
be lazy, for example? Can't the cases where the lazy property
needs to be controlled by client code be enclosed inside procedures
that do it in a thread-safe way?
>4. Modify Stdio implementation to properly initialize the new
>variables during module initialization.
>This change will be transparent to all clients.
>
>Now, with these changes, it will be possible for a client to know
>whether stdout, stderr, and/or stdin represent lazily allocated
>consoles or not, then act accordingly.
>
>For example, if I want to make sure messages written to stdout are
>recorded even for a GUI-app, but I don't want a popup, I could do the
>following:
> IF (Stdio.stdOut_IsLazy) OR (Stdio.stdout = NIL)
> THEN
> Stdio.stdout := FileWr.Open("myLogFile.txt");
> Stdio.stdOut_IsLazy := FALSE;
> END;
>Now the above code fragment does show the possibility of a race
>condition in multi-threaded code.
>
Rodney Bates
Retired assistant professor
Computer Science
More information about the M3devel
mailing list