I know that flex does not support multi threading however, I would like to clear a doubt.
I have two events that call a same function. Suppose the two events occur at the same instant (or in quick succession) will the handler be called twice, one after the other or there is a chance that if the handler function is taking too much time to execute the same handler can start executing simultaneously.
Thnanks
The handler will be called twice, once with each event. The second call (and essentially, the entire app) will be blocked until the first call has returned.
Here's a nice overview of the event cycle--doesn't specifically address your question, but it's a nice broad picture.
And you can't go wrong with the elastic racetrack.
Yes it will always get called twice. Yes one of the two calls will complete before the other is started. Unless you are doing something like dispatching an event in the handler for another handler to work on, then it all goes out the window! Even then I believe the first call will complete, but the event it dispatched may get resolved before the second call happens, sometimes....sorta. ;)
YMMV
If you didn't know, using PixelBender, Flex can do multi-threading. Other than for graphics, you can make use of pixelbender to do mathematical functions quickly which you may find a use for :)
Related
I'm developing a game in pyglet, that scheduled by a simple text file like :
0:00:01;event1
0:00:02;event2
0:00:03;event3
The fact is that, among these events, some might be blocking (for instance event2 might consist in displaying instructions until a key is pressed). As a consequence, event3 might not be executed at the proper time (i.e., during the event2). For now, my strategy is to schedule one event after the other :
Execute the first event
Once the first event is finished, compute the remaining duration between the first and the second event (delta_duration)
Schedule the second event with a delay of delta_duration
... and so on
For now, I did not succeed in implementing properly a blocking event with this strategy. It seems that anything blocking the event_loop (like a sleep call during event2) is preventing even the graphical elements of event2 (text instructions) to be displayed. On the other hand, if I do not put any blocking routine (sleep) in the event2, I'm able to see the vertices, but the scheduler keeps on scheduling (!), and so the event3 comes too soon.
My question is : what would be a general strategy, in pyglet, to articulate non-blocking to blocking events ? More precisely, is it possible (desirable) to use multiple clocks for that purpose ? The pyglet documentation mentions that multiple clocks can be used but it is not very well explained.
I don't want a solution that is specific to my events example but, rather, general indications about the way to go.
It's really up to your program on what blocks. If you are using input from Python for the console window, then yes that will block because it's blocking execution of Python in general. If you have a label popup in the window that is waiting for input from an on_key_press window event, then that is completely different as it's not blocking the pyglet loop, it was scheduled within it.
If your event is a 20 second long math calculation, then that should probably be ran in a thread. You will probably have to separate the types of events in order to differentiate how they should be ran. It's hard to say because without a runnable example or sample of code, I am just guessing at your intentions.
Although it sounds more like you are wanting some sort of callback system. When execution of func1 is declared done, go to func2. There is nothing built into pyglet like this, you would have to have a clever use of scheduling. There are examples of this using pure python though. I personally use Twisted Deferred's for this.
Can I have an boost::promise<void> created in a thread and set its value in another different thread through boost::promise<void>::set_value().
I think I am having a crash because of this, probably, so I must guess that no, but I would need confirmation. Thanks in advance.
P.S.: Note that I am using boost implementation.
Yes, you can do that, but you must ensure that the call to set_value() does not conflict with anything in the other thread, such as the completion of the constructor or the start of the destructor.
(According to the C++ standard you cannot even make potentially concurrent calls to set_value() and get_future() but that is a defect and should get fixed.)
To give a more precise answer it would be necessary to see exactly what your code is doing.
I'm using lua as the scripting language for handling events in my application, and I don't want to restrict users to writing short handlers - e.g. someone might want to have one handler run an infinite loop, and another handler would interrupt the first one. Obviously, lua doesn't directly support such behavior, so I'm looking for workarounds.
First of all, I'd like to avoid modifying the engine. Is it possible to set up a debug hook that would yield once the state has reached its quota? Judging by the documentation, it shouldn't be hard at all, but I don't know if there are any caveats to this.
And second, can I use lua_close to terminate a thread as I would in actual multithreading?
I've done something similar in the past. Its completely possible to multi-thread on separate Lua states. Be sure to take a look at luaL_lock() and luaL_unlock() (plus associated setup/cleanup), as you will no doubt need this setup (a simple mutex should do the trick).
After that, it should be a fairly simple matter of creating a lock/wait/interrupt API for your handlers.
In my application I run wglGetCurrentDC() and wglGetCurrentContext() from onThread function
(this function should be called as declared here - EVT_THREAD(wxID_ANY,MyCanvas::onThread))
and I get NULL in both cases. When I run it not from onThread it is ok…
What is work around in order to solve the problem – (I have to run them when getting event from the thread!)
As Alex suggested I changed to wxPostEvent to redirect the event to main thread, which catches the event in its onThread function.In this onThread function I have wglGetCurrentDC() and wglGetCurrentContext() calls ...They still return null.Please explain me what I am doing wrong. And how to solve he problem.
Maybe I'm misunderstanding, but should you not be using wxGLCanvas and wxGLContext rather than the windows-specific code? At the very least it's probably more compatible with other wxWidget code.
Anyway, from the wglGetCurrentDC documentation, the function returns NULL if a DC for the current window doesn't exist. This suggests that either the context was destroyed somehow or you're not calling it from the window you think you're calling it from (perhaps because of your threading?). I would reiterate what Alex said; don't call UI code from any thread besides the main one.
If you could post some code showing how you're returning from the thread it might help identify the problem. It seems likely that you're doing UI stuff from the thread and just not realizing it. (Hard to tell without seeing any code, though.)
Don't touch any UI-related stuff from a worker thread. This is general requirement for all UI frameworks. Use wxPostEvent to redirect a work to the main application thread.
my question is : how can I use SendMessage() to implement thread communication between two threads, one with a window (GUI) and the other with no window?
The problem is that SendMessage() needs a handle (HWND)?
Another detail about my project : Two threads, one running managed code (the one with the user interface), and the other running native code (the one without window)
Thank you very much!
I would suggest creating a hidden window. When using postthreadmessage, there is a chance that your message could get lost (ie: if a messagebox is running the message loop).
More info about that at:
http://blogs.msdn.com/oldnewthing/archive/2005/04/26/412116.aspx
Perhaps you should try to use PostMessage or PostThreadMessage
If the thread has no window, no message queue, and no message dispatcher, then it's going to be hard to a message to it. It is common for threads to create hidden windows just for communication purposes (take a look with Windows Spy and you'll see plenty of examples).
One alternative is to use shared memory and a synchronization primitive such an event or semaphore. Another alternative is to use pipes.
what #jdigital said. Note that if you create a hidden window, and your thread does not already implement a message loop (either in regular win32-speak, or one in the context of a COM STA -- and if you have no idea what I'm talking about then one probably does not exist in your thread), you'll also want to create a message loop as well. ATL makes it fairly easy with _AtlModule.RunMessageLoop(); Unfortunately this also means the thread in question is probably going to need to be event-driven while it is in the message loop. You can do tricky things like MsgWaitForMultipleObjects, but it gets hairy.
Here's an example of hidden windows if you're familiar with ATL/COM. I went through this pain a while back and thought there was a useful discussion on microsoft.public.vc.atl, but the best I can find now is this post. which goes into some detail about variants of message loops (what to do differently if you have keystroke accelerators or modeless windows, sounds like you don't in your application).