I need to call a javascript function from my plugin. In order to do that I have spawned a thread using npnfuncs->pluginthreadasynccall(savedinstance, wcfEventForwarder, NULL). Inside wcfEventForwarder thread function, I am waiting for messages (on a POSIX message Q) which are posted by another library. My intention is to receive these messages and then pass the data (received in these messages) to Javascript.
The issue is, when I am spwaing the thread using pluginthreadasynccall(...) from Invoke, the browser is hanging and I am not able to interact with the browser any more. Can you please help me with a solution?
Regards,
Souvik
You have completely misunderstood the purpose of NPN_PluginThreadAsyncCall; it is not to start a new thread, but to run something on the main thread. Your wcfEventForwarder function will be called on the main thread, so if you then block it's going to hang the whole plugin.
the purpose of this function call is to give you a way to trigger a call back on the main thread since other then NPN_PluginThreadAsyncCall, no NPN_ functions can be called on other threads. If you want to spawn another thread, you should do it yourself using something like boost::thread or the threading APIs directly (pick your flavor).
You should also note that some of the newer browsers have apparently stopped supporting NPN_PluginThreadAsyncCall; in particular, it doesn't seem to work in Safari 5.1 on windows or mac and I've had problems with it on multiple other browsers (firefox and chrome) in certain configurations on Mac.
Are you calling NPN_PluginThreadAsyncCall from another thread , or inside the "plug-in thread"?
Related
I am using pyscript to do image processing for a website I am making on hamming and reed solomon codes. It does however take a long time to load. I have a css loading animation but it freezes while the python image processing code is running. Is there a way for me to run my python scripts while still retaining HTML animation and function?
I have looked into multiprocessing and threading. Both seem unavailable in the current state of pyscript, pyodide and html. I am considering changing the css to a gif, but this doesn't fix other interactables on the website.
Python running in PyScript, just like JavaScript, is inherently limited to the single browser main thread (but see below). While the main thread is busy working on a synchronous (blocking) task, liking running a single function, all other interactivity on the page will be suspended.
The (current) way around this is to make your code either asynchronous, writing your code as a coroutine to periodically yield execution back to the Browser's event loop. For example, you could take a multi-step process and break it up with await-able events like asyncio.sleep():
import asyncio
async def myLongFunction():
doThing1("foo")
await asyncio.sleep(0)
doThing2("bar")
await asyncio.sleep(0)
return doThing3("baz")
asyncio.ensure_future(myLongFuction())
Simpler solutions may be available in the future. There's quite a bit of work currently on allowing PyScript to execute code in a web worker, which wouldn't block the main thread while executing, although the results must be passed as structured messages back and forth.
Additionally, having access to pthreads in Pyodide (the primary runtime underpinning PyScript) is a long-standing goal, but one that's inching closer to being possible.
we are using Sikuli with Java (Sikuli 1.1.1), but we are running into java.lang.ThreadDeath exception for a new client. In Java Configuration, we have selected mix code of Enable - hide warning and run with protections. Has anyone run into this issue before and what is the reason and possible fix?
Somewhere in the code Thread.stop() is being called.
According to the documentation don't do this! It releases all locks held by that thread may cause locked objects to be accessed in inconsistent state.
I'm trying to get FLTK running in my c++ project. I'm creating an OMNeT++ simulation and would like to use the GUI like an emulated host, that is, I can make a send button and the host attached to the GUI will queue up a message to send in the simulation.
The issue I'm having is that, when the FLTK window runs, it waits for a response which causes the whole simulation to freeze until I close the window. My solution was to run the GUI in a separate thread. However, now I'm getting this error:
Tcl_ServiceModeHook: Notifier not initialized
Below is the code for the class containing the thread and the GUI.
#include <Enumerations.H>
#include <Fl.H>
#include <Fl_Box.H>
#include <Fl_Widget.H>
#include <Fl_Window.H>
#include <GUI.h>
void GUI::callThread() {
t = std::thread(&GUI::openWindow, this);
}
int GUI::openWindow() {
Fl_Window *window = new Fl_Window(300,180);
Fl_Box *box = new Fl_Box(20,40,260,100,"Hello, World!");
box->box(FL_UP_BOX);
box->labelsize(36);
box->labelfont(FL_BOLD+FL_ITALIC);
box->labeltype(FL_SHADOW_LABEL);
window->end();
window->show();
return Fl::run();
}
All I do to call it is:
GUI *g = new GUI();
g->callThread();
If I instead just call openWindow() directly, The window opens fine but it waits for an action so the rest of the simulation is not able to continue.
I'm trying to make this cross-platform (Has to work on Mac and Windows). I tried Qt (too complicated to set up) and wxWidgets (make errors on my computer) so FLTK seemed like one of the next best choices.
If anyone knows how to fix this error or has any opinions on a better way to set up my GUI, I'm all ears. This just seemed like the only thing I could do.
OMNeT++ 5.0 and up has Qtenv, which is a QT based runtime (Tkenv is now deprecated), so the whole QT setup, dependency etc. is done for you by OMNeT++. Qtenv will be the default runtime in OMNeT++ 5.1
It's not really clear what you are trying to achieve. If you want to insert events into the event queue whenever you press a button, you definitely have to use a separate thread, but you have to clarify how the simulation and wall clock time is related to each other. If they must be synced, you need to implement a real-time scheduler that syncs the simulation time with the wall clock time. The sockets example in OMNeT++ does this and behaves similarly what you describe except that the external event inserted into event queue is coming from a socket (where you can attach with a browser) isntead of coming from a GUI.
If you don't care about synchronization i.e. you want to use this for some kind of demonstration, then you don't have to use a real-time scheduler, but you should be aware the OMNeT++ is inherently single threaded and your GUI is running in a separate thread, so you have to sync those too. i.e. It's absolutely forbidden to access ANYTHING that OMNET is using from the GUI thread (or bad things will happen).
And the poor man's solution: if you just want to trigger an event (i.e. you really need only a button). Write an application in the host which regularly polls a volatile bool parameter. If it finds the parameter "true" it sends the event and then sets the parameter to "false". Now how you trigger an event? You can browse the parameters of the given node in the property inspector (lower left panel in runtime) and you can change it's value by hand back to true, then allow the simulation to continue. On the next poll, the host's app will detect again that the parameter is true and do the sending again. Obviously it's limited, but it gives a limited interaction without writing too much code (and all the multithreading issues are handled by the runtime itself)
I am using perl tray from activestate and have a question. I am wanting to make some type of ui or way for a user to set "Settings" on my application. These settings can just be written / read from a text file that is stored on the users computer.
The part I am not understanding though is how to go about making a ui. The only thing i can think of is showing a local perl page that runs on their computer to write to the file. However, I'm not sure how i could get perl to run in the browser when only using perltray.
Any suggestions?
PerlTray is an odd duck. It has an implicit event loop that kicks in after you either fall off the end of your program or after your 1st call to exit(). This makes it incompatible with most other common GUI event loops or most mini-server techniques that operate in the same process & thread.
2 possibilities come to mind:
Most Likely you'll have success spawning a thread or process that creates a traditional perl GUI or a mini-server hosting your configuration web-app. I'd probably pick Tkx, but that's just my preference.
I have a suspicion that the Event Loop used by Win32::GUI may actually be compatible with the event loop in PerlTray, but some experimentation would be required to verify that. I generally avoid Win32::GUI because it's not platform independent, but if you're using PerlTray, you're tied to Windows anyway...
I'm currently modifying a script used to backup cisco ACE modules' contexts & crypto files. it works absolutely beautifully with one device. however, when i use it on another module, it seems to go completely out of sync and it messes up the script.
From what I can see, the differences are in the presence of a line that the ACE module throws up as so: Warning: Permanently added '[x.x.x.x]' (RSA) to the list of known hosts.\r\r\n this just seems to throw the rest of the script off, even though none of my expect statements are even looking for this!
I've had nothing but nightmares with expect and the way in which it interprets information from ace modules; can anyone shed any light on this issue or provide any advice as to how to make these devices behave when I try to script for them?
If you're handling one connection at a time, you should make sure you fully terminate one before opening the next. The simplest way of doing that is to put:
close
wait
At the end of the (foreach) loop over the things to connect to.
If you were doing multiple connections at once, you'd have to take care to use the -i option to various commands (notably expect, send and close) and make everything work right in addition to fixing the things I mentioned earlier. It can be done, but it's considerably more tricky and not worth it if you don't need the parallelism.