in reply to Re^3: Threads + OpenGL act weirdly?
in thread Threads + OpenGL act weirdly?

Wow. Thanks a lot, i learned a good bit about threads from this and have managed to launch the thread in a manner that eradicates the error message and probably makes the thread a lot happier by not encumbering it with the OpenGL stuff unnecessarily: 
use threads;
use threads::shared;
use Carp;

use Config::Simple;

use Win32::OLE('in');
my $memory_use;
my %c;
BEGIN {
    share($memory_use);
    tie %c, 'Config::Simple', 'lifevis.cfg';
    sub update_memory_use {
        my @state_array;
        my $pid        = $PROCESS_ID;
        my $sleep_time = ( $c{sync_delay} * $c{full_update_offset} ) /
+ 1000;
        my $WMI_service_object = Win32::OLE->GetObject("winmgmts:\\\\.
+\\root\\CIMV2")
          or croak "WMI connection failed.\n";
    
        while (1) {
            @state_array = in $WMI_service_object->ExecQuery(
                'SELECT PrivatePageCount FROM Win32_Process'
                  . " WHERE ProcessId = $pid",
                'WQL',
                0x10 | 0x20
            );
            $memory_use = $state_array[0]->{PrivatePageCount};
            sleep $sleep_time;
        }
        return 1;
    }
    my $thr = threads->create( \&update_memory_use );
    $thr->detach();
}

use OpenGL qw/ :all /;

[download]

I wasn't planning to actually use OpenGL threaded anyhow, but actually only wanted to offload blocking operations that can work in the background.

One thing i stumbled across though: Do you think it would be possible to safely create a thread that binds the glut keyboard input callbacks and then creates a second opengl main loop that processes ONLY those? Alternatively, is there a way to do event systems directly within perl or while loops that can react quickly, but don't use up 100% CPU?

In a similar vein: If i would, say, declare $sleep_time above outside the thread, then modify it in the main program, would the changes be noticed by the thread or would it need to be shared first?

Replies are listed 'Best First'.
Re^5: Threads + OpenGL act weirdly?
by BrowserUk (Patriarch) on Sep 28, 2008 at 15:26 UTC

    Hmm. About all I can say is that you are moving in uncharted waters. threads used to carry a dire warning about creating threads inside special blocks:

    Creating threads inside BEGIN, CHECK or INIT blocks should not be relied upon. Depending on the Perl version and the application code, results may range from success, to (apparently harmless) warnings of leaked scalar, or all the way up to crashing of the Perl interpreter.

    And, unlike some of the other overly pessimistic warnings about threads, I've personally experienced intermittant failures and traps when using threads created within BEGIN{} blocks. From memory, these occured with both 5.8.3 and 5.8.5, hence I gave up trying long ago. I don't have a handle on how things stand on later builds.

    That warning has now disappeared from the latest cpan version of threads, but there's no real way to know if it was deliberately removed because the cause had been found and fixed, or if it just got omitted along the way.

    Do you think it would be possible to safely create a thread that binds the glut keyboard input callbacks and then creates a second opengl main loop that processes ONLY those?

    The whole area of callbacks and threads is pretty iffy. Even conceptually. What happens if the code doing the calling back is running in a different thread to that which passed in the address to be called back?

    At the C-level, provided that the callback routine is reentrant and doesn't rely on thread local storage, it'll probably work ok. But in Perl, I really have no idea what would happen, but my gut feeling is that it wouldn't be good.

    And the idea of running two "main loops" seems very unlikely to work.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
      As for the BEGIN block, it seems to work well. Aside from some complaints about freed pools that randomly occur when closing the application, i haven't noticed any problems.

      Regarding two main-loops, yea, that does indeed not work. As soon as the first mainloop in the thread starts the whole application closes. But that's no big problem, as Corion below already provided the exact thing i needed. :)
[reply]
Re^5: Threads + OpenGL act weirdly?
by Corion (Patriarch) on Sep 28, 2008 at 14:04 UTC

    I would keep all things related to OpenGL within one thread, and preferrably the main thread. Have the OpenGL thread read from a Threads::Queue and write to another queue to process the events. You might have luck in that, at least on Windows, the GLUT callbacks won't interfere with the OpenGL drawing stuff, so you can of course try to instantiate these callbacks from within their own thread.

    Also, for all things asynchronous, look beyond threads at POE, which is an event-based framework and at Coro, which uses userspace threads and thus circumvents almost all synchronisation problems. The author of Coro also writes Deliantra, a multi-user game using OpenGL, so likely you'll be able to use OpenGL with Coro.

[reply]
      Thank you! You have provided me with *exactly* what i needed.

      While probing at Deliantra wasn't too successful, since its core is a .xs program and only the fluff around is Perl, Coro is pretty much perfect for my needs.

      It was a matter of minutes of making my data synch routine run in a Co-Routine, and a matter of a few hours of testing to tweak the balance of "cede"s inside the synch routine and in the normal loop to match up nicely as well as some extra variables to prevent it from running multiple synchs at the same time. Now i have a perfectly parallelized application that runs smoothly even under heavy load.

      If you want to have a look:
      http://www.veoh.com/videos/v16083518yDCkDfcH
      http://www.veoh.com/videos/v16083519Y5TFBsk6
[reply]
        and a matter of a few hours of testing to tweak the balance of "cede"s inside the synch routine and in the normal loop to match up nicely

        That is the problem with cooperative threading/event systems: balancing the needs of the various concurrent processes so that the high speed events are processed in a timely fashion without breaking up the long running parts in to such iddy biddy chunks that nothing ever gets done. And the more concurrency you need the harder that balancing act becomes.

        But the very worst part is that just as soon as you get everything balanced and cooperating nicely, the requirements change--a new one is added or an existing one is no longer required and you have to start the whole process over from scratch. I remember one such system in a production environment that processed the same three dummy datafiles over and over hundreds of time every day--in each of 300 stores--for years, simply because it was easier, than trying to remove that processing and re-balance the system.

        The users could not believe how much more responsive the systems were when we replaced the old, cooperative DOS-based system with one that multi-tasked under OS/2. A part of the change was because of newer faster hardware, but most of it came simply because 40% of the cpu's time was no longer being used to 'busy work', processing files that were no longer required, but too difficult and risky to consider removing. We calculated that over the preceding 4 years, those same three files had been pointlesly reprocessed just short of a billion times!

        The reason preemptive multi-tasking predominates, is because you write simple, linear flows for each task and let the scheduler take care of mixing them up. When an old task is no longer needed, or a new task it required, you just add or remove it. You don't have to go messing with everything else in the system to restore the balance.

        Anyway, I'm glad you found a solution that works for you. As an aside, if the code isn't proprietary, I'd love to get a copy and see if it's possible to do what you need with threading?

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

In Section Seekers of Perl Wisdom