1

I've written a windowless NPAPI plugin, and I am going to perform some long lasting operation (e.g.send a http post request with image data) in a plugin function called by web browser JavaScript.

To prevent web browser from hanging, I create one worker thread for every lengthy operation.

My question is that if the browser is closed while there are still worker threads running, how can I prevent my plugin instance from being destroyed (in NPP_Destroy?) before worker threads completed?

For ActiveX control, I simply add/release plugin instance's reference count every time the worker thread is launched/completed. But for NPAPI plugin, the reference count is just for NPObject(created via NPN_CreateObject) instead of plugin instance itself. Now I get baffled.

Any help would be really appreciated.

winhow
  • 145
  • 1
  • 10

1 Answers1

2

You can't. I suppose you could launch another process and perform the operations in that; that way you could send it a signal when the plugin shuts down and say "you need to close, when you're ready" but not have it close 'til it finishes.

The plugin itself -- even in IE -- you can't control when it shuts down because if the browser shuts down it'll close all plugins at that point anyway.

Welcome to plugin land -- you don't get to control the lifecycle.

taxilian
  • 14,229
  • 4
  • 34
  • 73
  • I Just come to plugin land in M​​arch this year:). "in IE, you can't control when it shuts down because if the browser shuts down it'll close all plugins at that point anyway" But in IE, I could use AddRef()/Release() to control the lifetime of my plugin instance, and indeed the plugin itself won't be destroyed 'til the worker thread decrease the plugin's ref count to 0. When browser shuts down, it only decrease the plugin's ref count by 1, and the plugin won't be destroyed if I increase ref count by 1 when the worker thread is launched in advance(I've run debug mode to verify this). – winhow Nov 26 '13 at 02:11
  • Correct me if i am wrong. I think it should be common for NPAPI plugins to have worker threads for long lasting operations. Then what if the browser is closed immediately while the worker threads just start doing their jobs? If the plugin instance is destroyed, access violation can easily happen in worker threads since the plugin's member data is now invalid. If another process is the only way to handle this situation, does that means I have to launch all my worker threads in another process (to prevent the mentioned access violation)? It seems not so common for me to do like this.. – winhow Nov 26 '13 at 02:44
  • 1
    The IE situation is a little different due to it using the COM architecture. Every other browser launches plugins in child processes (or formerly in their own process) and doesn't let you control lifetime. Long-running worker threads should have regular interruption points where you can cancel them, even outside plugin life-cycles: users might want to close your app, the system is shutting down, ... – Georg Fritzsche Nov 26 '13 at 15:52
  • In addition, my experience is that IE will kill your activex control even if the refcount is still positive if the process is shutting down and you haven't cleaned up yet. As @GeorgFritzsche says, you are in a separate process with NPAPI and there is no way to tell the browser not to shut you down. They actually consider long running threads not connected to a particular (existing) plugin instance to be a security hazard, I suspect. – taxilian Nov 26 '13 at 19:45