I tried switching to getline stringstream combo and also using the ignore
statement to ignore previous content in the buffer. It still gave me the same
non blocking result though.
I received your code, I will have a look at it, thanks :)
Kind Regards
Christoffer
--
Read this
Hello, I'm trying to write a program where the renderer is running on a
separate thread. On the main thread I want to control the command line inputs
but as soon as I add scenedata to the osgViewer which is stored in the renderer
then the renderer takes over the standard input. std::cin in the
Hello,
This problem occurs when I run the code on an old machine with intel core 2
duo,Nvidia quadro FX 580, 4gb ram, OS=Slackware. If I run this code on another
machine with Intel i7-3770, AMD Radeon 7800 series (2gb), 12gb ram, OS=Red Hat
then the code runs just fine.
Do you have any ideas
Hi Christoffer,
On 25 September 2012 12:39, Christoffer Pettersson hoffe...@hotmail.com wrote:
This problem occurs when I run the code on an old machine with intel core 2
duo,Nvidia quadro FX 580, 4gb ram, OS=Slackware. If I run this code on
another machine with Intel i7-3770, AMD Radeon
hmm ok. I tried the code on another computer with specifications between the
two computers mentioned before. This one running Slackware as well. And the
code ran fine on this one. Theyre using the same terminal and as far as I know
they also use the same compiler.
As I mentioned before,
On 09/25/2012 12:04 PM, Christoffer Pettersson wrote:
hmm ok. I tried the code on another computer with specifications between the
two computers mentioned before. This one running Slackware as well. And the
code ran fine on this one. Theyre using the same terminal and as far as I know
they
Maybe would be easier to do a client-server approach to give orders to the
renderer (server) and that the client program would hear the terminal
orders.
2012/9/25 Jason Daly jd...@ist.ucf.edu
On 09/25/2012 12:04 PM, Christoffer Pettersson wrote:
hmm ok. I tried the code on another computer
Hi Robert,
That is pretty much what I'm doing, just the other way around. The main thread
is responsible for handling standard inputs, while the second thread is
responsible for handling the renderer.
Hi Jorge,
That is exactly what I try to mimic using the current design :) I cant add
On 9/25/2012 5:01 PM, Christoffer Pettersson wrote:
Hi Jason,
That is pretty much what I'm doing, just the other way around. The main thread
is responsible for handling standard inputs, while the second thread is
responsible for handling the renderer.
I didn't see the code you posted
The cin in the thread is only there for demonstration purposes. It was used to
test the blocking of the cin function. If i write cin in the render thread then
the program is halted. If i write it in the main thread it is not halted. The
model code is also just for demonstration. That part of
On 9/25/2012 5:27 PM, Christoffer Pettersson wrote:
The cin in the thread is only there for demonstration purposes. It was used to
test the blocking of the cin function. If i write cin in the render thread then
the program is halted. If i write it in the main thread it is not halted. The
The cin in the render thread is not supposed to be there. They were just put
there to see if they would block or not, which they did. The problem i have is
that if i write cin in any other thread than the render thread, then the thread
containing the cin command does not block. It jumps over
On 09/25/2012 05:45 PM, Christoffer Pettersson wrote:
The cin in the render thread is not supposed to be there. They were just put
there to see if they would block or not, which they did. The problem i have is
that if i write cin in any other thread than the render thread, then the thread
Hi Christoffer,
The OSG does absolutely nothing with standard input, go have a look at
the whole source code base. standard error and standard output are
used for debug and info messages but nothing is read.
So... this has to be a non OSG specific programming question, which I
suspect is likely
14 matches
Mail list logo
