I'm using the Pepper plugin on Android Studio. I have the robot emulator and device emulator running fine, but when I run the application, I get this weird threadpool spawning error. I've gone through the entire install tutorial and made sure everything was right, but I can't get around this. It happens most of the times that I run it, but sometimes it runs without any issues. Thanks!
07-29 11:38:29.474 2625-2643/com.tammy.tammygame E/qi.eventloop: Threadpool MainEventLoop: System seems to be deadlocked, sending emergency signal
07-29 11:38:29.474 2625-2643/com.tammy.tammygame A/qimessaging.jni: Emergency, aborting
07-29 11:38:29.474 2625-2631/com.tammy.tammygame I/art: Thread[3,tid=2631,WaitingInMainSignalCatcherLoop,Thread*=0xa682e700,peer=0x12c790a0,"Signal Catcher"]: reacting to signal 3
07-29 11:38:29.479 2625-2631/com.tammy.tammygame W/art: Method processed more than once: android.os.Message android.os.MessageQueue.next()
07-29 11:38:29.483 2625-2631/com.tammy.tammygame W/art: Method processed more than once: void java.lang.Daemons$ReferenceQueueDaemon.run()
07-29 11:38:29.484 2625-2631/com.tammy.tammygame W/art: Method processed more than once: java.lang.ref.Reference java.lang.ref.ReferenceQueue.remove(long)
07-29 11:38:29.484 2625-2631/com.tammy.tammygame W/art: Method processed more than once: boolean java.lang.Daemons$FinalizerWatchdogDaemon.waitForObject()
07-29 11:38:29.486 2625-2631/com.tammy.tammygame W/art: Method processed more than once: void java.lang.Daemons$HeapTaskDaemon.run()
07-29 11:38:29.490 2625-2631/com.tammy.tammygame W/art: Method processed more than once: void java.util.Timer$TimerImpl.run()
07-29 11:38:29.497 2625-2631/com.tammy.tammygame E/art: Unable to open stack trace file '/data/anr/traces.txt': No such file or directory
07-29 11:38:29.976 2625-2643/com.tammy.tammygame I/qi.eventloop: Threadpool MainEventLoop: Size limit reached (658 timeouts / 20 max, number of tasks: 690, number of active tasks: 8, number of threads: 8, maximum number of threads: 8)
07-29 11:38:29.976 2625-2643/com.tammy.tammygame E/qi.eventloop: Threadpool MainEventLoop: System seems to be deadlocked, sending emergency signal
07-29 11:38:29.976 2625-2643/com.tammy.tammygame A/qimessaging.jni: Emergency, aborting```
The Qi SDK and its underlying framework, libQi, produce threads automatically for your callbacks (for subscriptions of future continuations). But this is limited in hard code to 8 threads for Android clients, which is not so much. When they are all busy, the communication with the robot is blocked, and apparently the program is aborted too.
To avoid this kind of issue you must be cautious of the code you write in these callbacks (onRobotFocusGained is also one of them), and avoid blocking code there. To do so, remember to always call Qi SDK methods via asynchronous interfaces, for instance say.async().run() instead of say.run(). That would return a Future f, and the continuation of your code would land in the callback of f.andThen(...).
If you are using Kotlin, you can avoid this tiresome gymnastic by using coroutines, via suspend functions. A suspend awaiting a result from a future would stop there, freeing the thread, and resume execution upon receiving the result. Qi's notion of Future is compatible with coroutines. Here is a file you can put in your project to extend Qi's Future for coroutines. With this, you can call say.async().run().await() and wait for the result without blocking the thread. Yet, it looks synchronous, so it is convenient for you as a developer.
Related
So I am trying to understand the message processing code of Unreal Engine on Windows OS, and I didn't find any frequent usage of the function MsgWaitForMultipleObjects or MsgWaitForMultipleObjectsEx in the message pumping code.
The engine message pumping goes like this:
MSG Message;
// standard Windows message handling
while(PeekMessage(&Message, NULL, 0, 0, PM_REMOVE))
{
TranslateMessage(&Message);
DispatchMessage(&Message);
}
For context, this code will run every frame one to three times, meaning the code will be executed each 2 - 5 milliseconds on average throughout the running time of the application. A) Does that make wait functions unnecessary? or am I missing something here!
B) Is there any rough estimation of how long an application could be busy doing 'other stuff' before processing incoming messages? For instance if an application only processes messages every 50 millisecond, is that a bad practice? or is that a reasonable way of doing it? And what if the period became 500 milliseconds and so?
Use MsgWaitForMultipleObjects/etc if you need to both handle window message processing and kernel handle or alertable waits in a single thread. If you are only doing message processing then simply use a normal GetMessage based message loop, if only doing kernel handle or alertable waits then use WaitForMultipleObjects as appropriate.
I've been using code that I found in the following post:
How to get thread state (e.g. suspended), memory + CPU usage, start time, priority, etc
I'm examining thread state, and there's the following enum that describes the reasons for thread 'waiting' status -
enum KWAIT_REASON
{
Executive,
FreePage,
PageIn,
PoolAllocation,
DelayExecution,
Suspended,
UserRequest,
WrExecutive,
WrFreePage,
WrPageIn,
WrPoolAllocation,
WrDelayExecution,
WrSuspended,
WrUserRequest,
WrEventPair,
WrQueue,
WrLpcReceive,
WrLpcReply,
WrVirtualMemory,
WrPageOut,
WrRendezvous,
Spare2,
Spare3,
Spare4,
Spare5,
Spare6,
WrKernel,
MaximumWaitReason
};
Can anyone explain what WrQueue is, and perhaps what the difference between WrUserRequest and UserRequest is?
The information is obtained using NtQuerySystemInformation() with SystemProcessInformation.
WrQueue this is when thread waits on KQUEUE object (look it definition in wdm.h) in kernel. this can be call to ZwRemoveIoCompletion or Win32 shell GetQueuedCompletionStatus (IOCP is exactly KQUEUE object). or thread (begining from vista) call ZwWaitForWorkViaWorkerFactory (worker factory internally use KQUEUE. also possible that thread in kernel calls KeRemoveQueue - this usually does system working threads.
WrUserRequest is used by win32k.sys subsystem. Usually this is when thread calls GetMessage. So if we view WrUserRequest we can be sure that thread is waiting for window messages.
UserRequest - this means that thread waits on some object[s] via WaitForSingleObject[Ex] or WaitForMultipleObjects[Ex] or MsgWaitForMultipleObjects[Ex] (or it equivalents)
I've been working with the Message Hub sample code found at this link: https://github.com/ibm-messaging/message-hub-samples
In particular, I've been trying to increase the throughput of the producer with the Kafka Java console example. I noticed the documentation in this snippet of code:
// Synchronously wait for a response from Message Hub / Kafka on every message produced.
// For high throughput the future should be handled asynchronously.
RecordMetadata recordMetadata = future.get(5000, TimeUnit.MILLISECONDS);
producedMessages++;
I've already turned off the thread sleep found later in the code which also helped increase the throughput, but I was hoping I could get some help on implementing the future asynchronously in this block. Thanks in advance!
you have two basic options for handling the outcome of a produce request asynchronously
1) use the overloaded send with a completion callback argument, which will be invoked asynchronously:
public Future<RecordMetadata> send(ProducerRecord<K, V> record, Callback callback);
if using the callback you may ignore the future.
2) pass the Future to some other thread you have created, and have it inspect the future for completion, while leaving the thread that calls send free to carry on.
I have the classic IOCP callback that dequeues i/o pending requests, process them, and deallocate them, in this way:
struct MyIoRequest { OVERLAPPED o; /* ... other params ... */ };
bool is_iocp_active = true;
DWORD WINAPI WorkerProc(LPVOID lpParam)
{
ULONG_PTR dwKey;
DWORD dwTrans;
LPOVERLAPPED io_req;
while(is_iocp_active)
{
GetQueuedCompletionStatus((HANDLE)lpParam, &dwTrans, &dwKey, (LPOVERLAPPED*)&io_req, WSA_INFINITE);
// NOTE, i could use GetQueuedCompletionStatusEx() here ^ and set it in the
// alertable state TRUE, so i can wake up the thread with an ACP request from another thread!
printf("dequeued an i/o request\n");
// [ process i/o request ]
...
// [ destroy request ]
destroy_request(io_req);
}
// [ clean up some stuff ]
return 0;
}
Then, in the code I will have somewhere:
MyIoRequest * io_req = allocate_request(...params...);
ReadFile(..., (OVERLAPPED*)io_req);
and this just works perfectly.
Now my question is: What about I want to immediately close the IOCP queue without causing leaks? (e.g. application must exit)
I mean: if i set is_iocp_active to 'false', the next time GetQueuedCompletionStatus() will dequeue a new i/o request, that will be the last i/o request: it will return, causing thread to exit and when a thread exits all of its pending i/o requests are simply canceled by the system, according to MSDN.
But the structures of type 'MyIoRequest' that I have instanced when calling ReadFile() won't be destroyed at all: the system has canceled pending i/o request, but I have to manually destroy those structures I have
created, or I will leak all pending i/o requests when I stop the loop!
So, how I could do this? Am I wrong to stop the IOCP loop with just setting that variable to false? Note that is would happen even if i use APC requests to stop an alertable thread.
The solution that come to my mind is to add every 'MyIoRequest' structures to a queue/list, and then dequeue them when GetQueuedCompletionStatusEx returns, but shouldn't that make some bottleneck, since the enqueue/dequeue process of such MyIoRequest structures must be interlocked? Maybe I've misunderstood how to use the IOCP loop. Can someone bring some light on this topic?
The way I normally shut down an IOCP thread is to post my own 'shut down now please' completion. That way you can cleanly shut down and process all of the pending completions and then shut the threads down.
The way to do this is to call PostQueuedCompletionStatus() with 0 for num bytes, completion key and pOverlapped. This will mean that the completion key is a unique value (you wont have a valid file or socket with a zero handle/completion key).
Step one is to close the sources of completions, so close or abort your socket connections, close files, etc. Once all of those are closed you can't be generating any more completion packets so you then post your special '0' completion; post one for each thread you have servicing your IOCP. Once the thread gets a '0' completion key it exits.
If you are terminating the app, and there's no overriding reason to not do so, (eg. close DB connections, interprocess shared memory issues), call ExitProcess(0).
Failing that, call CancelIO() for all socket handles and process all the cancelled completions as they come in.
Try ExitProcess() first!
I need to trasmit with a (Boost) tcp server information collected in real time by the ARToolKit video tracking library.
Which is the right way of doing it?
I'm actually doing it with Boost threads and asio, but I think that what I do is done in a bad way (even if it works)
Here is what I do to run the server (the source of the Server class is from Boost tutorial):
boost::asio::io_service io_service;
Server s(io_service, 2345);
boost::thread bt(boost::bind(&boost::asio::io_service::run, &io_service)); //server in background in a second thread
Then I start the video tracking
startTracking(); //blocking call in the main thread
defined in this way
void startTracking(){
glutInit(&argc, argv); //global and reachable
if ((gArglSettings = arglSetupForCurrentContext()) == NULL) {
fprintf(stderr, "main(): arglSetupForCurrentContext() returned error.\n");
exit(-1);}
... //init a lot of artoolkit parameters
arVideoCapStart();
argMainLoop( NULL, keyEvent, mainLoop );
}
In this (horrible) way everything works. But I would like to avoid spawning a second thread for the asio server (it is not supposed to be thrown there, as I read from the Boost doc).
Otherwise trying to put the video traking out of the main thread crashes the ARToolKit library ie:
boost::thread workerThread(startTracking);
workerThread.join();
When the join() is run the program segfaults at glutInit call
What do you think the workerThread.join() method does? Take a look at the answer to this question. So, calling the join method will cause the thread it is called from (main thread) to block and wait until the worker thread has completed. Is that what you want? If you have set up ASIO to run on that main thread, then none of the ASIO I/O socket handlers will be able to execute and thus it will appear to hang because the thread it is on is frozen from the join method. Likewise for the ARToolKit library, if the calls to it have been initiated on this main thread, then it too will appear to freeze because that thread is frozen when the join method is called.
If this is not your problem, then please provide more code.