[Bf-committers] Blender Web Plugin :: Thread vs Fork

[Roger Wickes]

my 2-cent probably worthless thought: We would fork a process so that if it crashed or got deadocked, it would not bring the core server down with it or lock it. We could control CPU allocation and see it in the process list as a separate element. If that principle applies to tasks running under a browser, I would stay with the forking and have it essentially run as a subprocess, separate from the other tabs and processes and applets that are also running concurrently. I just had this yesterday in IE where an ActiveX control in one tab crashed the whole browser. Conversely, if it is a fork, it might not be nearly as affected when other processes/applets/plugins fail. 

 ----------------
Sent by Roger Wickes for intended recipient. If you are not the intended recipient, please delete this message and contact Mr. Wickes immediately.


Atlantica Investments, Inc.
PO Box 680310, Marietta, GA 30068 USA



----- Original Message ----
From: Marcelo Coraça de Freitas <mfreitas at ydeasolutions.com.br>
To: bf-committers at blender.org
Sent: Thursday, September 25, 2008 4:51:05 PM
Subject: [Bf-committers] Blender Web Plugin ::  Thread vs Fork

Hello all,

    Something occurred to me right about now.

    The original problem with the Firefox Blender Web Plug-in is that there was a dirty lock for rendering with OpenGl in the plugin Window. That's solved with xembed. What just occurred to be is that, with xembed, there is no real need for forking the process.

    Even though forking the process gives us more stability, as if blender crashes the browser keeps going, it's a lot slower than threads (simply because for each plugin instance there will be needed to initialize the entire game engine - load the engine code into the memory and running it's main - and harder to script - even using dbus.

    If we work with threads that's solved. And we also gain something that's quite important: the ActiveX plugin work with threads and there is no locking in the opengl context (there is a data locking for something I didn't quite understand yet, but I've seen some examples over the web where people render OpenGL into the control's window without locking anything!

    We could have then a common code in both web plugins. But there is also another problem. The game player uses some global variables (I know only about one, the G variable - which has gave me some headaches in the past plugin code), so refactoring is needed in order to implement this approach. But, once it's achieved we'd have a code that's easier to maintain - as the plugin and the stand alone player would be different applications, sharing a great part of the code.

    Those are only initial thoughts. I might come up with some testing code so I can make sure it'll work as expected. 


Regards,




Marcelo Coraça de Freitas 
Gerente de TI 

Ydea Desenvolvimento de Software LTDA. 
Av. Adolfo Pinheiro, 2338 - Alto da Boa Vista 
CEP.:04734-004 - São Paulo - SP 
Tel.: 55-11-5523-0333
Tel.: 55-11-8685-1429  


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-committers/attachments/20080926/0aa10514/attachment.htm