[M3devel] proposal for dealing with lazy console--please review and comment!

[Randy Coleburn]

Hi Rodney:
 
Thanks for your reply.
 
The issue is that for cm3 on Windows you can specify -gui as a command line option.  This option causes the program to be built as a Windows GUI-mode application, rather than as a console application.  For a GUI-mode application, the Stdio file handles are NIL because it has no console.
 
Seemingly, to prevent a lot of errors when trying to read/write Stdio, some folks introduced the idea of a lazy console post cm3 v4.1.  What happens now "under the covers" is that on a GUI-mode program the Stdio file handles are allocated as Lazy Consoles.  Then, whenever Stdio.stdout/stderr/stdin is used, the underlying code realizes the first use and magically allocates a new console window on the fly.  This console window pops up on the screen on top of your GUI-mode window.
 
My objection is that this behavior is not documented in any interface and the programmer has no way to control the behavior.  I want to make such control possible.
 
Hope this explanation helps a bit.
 
Regards,
Randy

>>> "rodney.bates" <rodney.bates at wichita.edu> 6/18/2008 10:36 AM >>>
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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080618/04f451e5/attachment-0002.html>