[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