[Bf-committers] Console patch update and question about Mac usage

[Jacques Beaurain]

Hi,

Thanks for the good review. Some of my comments below...

-----Original Message-----
From: bf-committers-bounces at projects.blender.org on behalf of Jean-Luc Peurière
Sent: Tue 8/29/2006 8:22 PM
To: bf-blender developers
Subject: Re: [Bf-committers] Console patch update and question about Mac usage
 

>Now i agree the -c option should enable the redirection, not the  
>other way around on systems with a real console.
>
>I personally redirect the system console on my desktop, so i can see  
>output from all applications at once, so i'm not keen
>with someone or something else messing with that.

Without the -c flag there is no "messing" with the std streams so this is the way it is already.

>
>quick look at the patch (will do more later) :
>
>there is 1870 +/- lines of JMS hotkeys reference script, that dont  
>belong here

I made a note in the tracker about this when I uploaded the patch. There is only one line different (a documentation entry for the hotkey) but CVS diff insists on marking all the lines as different. I believe it is some line ending problem with that file. I made sure the patch works correcty against a clean CVS that day, but we can certainly leave out that file for now.


>
>Thread safety must be insured. More, any openGL call or function that  
>call one can be
>only done in the main thread, i think (no guarantee of valid context  
>in GHOST).
>

As far as I understand it allqueue justs queues a redraw for the main message loop so no OpenGL calls from my threads. So as long as we protect the queue with a locking mechanism it should be fine. I may be wrong about this.


>why unbuffering stderr ?
>
>from man : The standard error stream stderr is always unbuffered.
>
>for stdout, wont it be safer to unbuffer only the output of the pipe ?
>
>

By buffering the std streams a user may not see printed lines immediately because the buffer will wait until it is full before flushing to the streams.


> From a general point of view, having 2 secondary threads (and 4 fd  
>open in 2 pipes)  just for reading the error messages,
>seems to me more than a bit overkill.
>

That is the only real way to properly intercept the std streams without possibilities of deadlock etc. I did quite a bit of research on this. It is very low CPU threads and 4 handles are really not that much (each process can handle quite a bit more than that AFAIK) so it should not hamper anything that I can think of.


>What we need to read here ?
>
>- messages from python.
>- printf or cout message in the main code.
>
>For the latter, it should be easy to set-up something like  
>GEN_messaging (used in GE C++), as those messages are
>all defined by the coder, simply open 1 or 2 new fd for all messages.

This can still be done, I did not do this initially because replacing all the printf's in code would have made for a very hard to maintain patch indeed and I am unsure if I would have ever convinced the devs to accept it. Now that the structure is there (and it is only enabled with -c) it may be possible to do this systematically once the code makes it into CVS first.

>
>For the former, cant we intercept messages before they are sent to  
>output ? Being not a pythoner, i have not the answer,
>but that i would find cleaner.
>

That is exactly how I intercept the Python messages already, it is not done using the std redirection threads.

>As Nathan pointed out, not linking against console subsystem will  
>eliminate the dosbox on windows, so the matter is only
>to intercept messages properly.

Both can be supported with the patch in its current state without changing the link flags (http://msdn.microsoft.com/library/en-us/dllproc/base/freeconsole.asp?frame=true)

Jacques
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 5146 bytes
Desc: not available
Url : http://projects.blender.org/pipermail/bf-committers/attachments/20060829/20b25f3e/attachment.bin