Re: [openvrml-develop] Status update: modularization

[Braden M. <br...@en...>]

On Mon, 2006-10-23 at 02:36 +0200, Josip Almasi wrote:
> Braden McDaniel wrote:

[snip]

> > At the moment, I'm just planning on running the VM in OpenVRML's main
> > (rendering) thread. I could give the VM its own thread if I need to--and
> > in that case I'd simply use something along the lines of an active
> > object pattern to transmit data--no separate process, so no pipes.
> 
> IOW JNI method calls.
> Well then a nasty script could hang the main thread... or, say, a 
> TimeSensor routed to it?
> ... no big deal, now that I think of it some more.

Right. Scripts block--period. It doesn't matter if they're in another
thread--all that means is that a request is dispatched to the script
thread and the rendering thread has to wait on it to be processed.

> Once you start a jvm it can start its own threads, in fact even java 
> scripts can start their own threads.
> So there's no point in trying to prevent eventual mess a script can do.
> Some reasonable strategy I use in somewhat simillar case is startup in 
> multiple threads, so they can't hang main, and main doesn't have to wait 
> for initialization.
> Applied to vrml java scripts, like,
> if (method initialize() exists) {
>    (new Thread( script )).start()
> } else {
>    try { script.run() } catch ( Throwable t ) {...}
> It's probably overkill for scripts...

Maybe not. Or not quite, anyway.

I ought to spawn a new thread to download the script code, at the very
least; I don't want to have the rendering thread block on that. I
*could* just keep that thread running and run the script in it and do
the active object thing.

I'll have to play around with how all this works. I'm starting to get to
far ahead of myself without having gotten some basic code running.

> > As for loading the classes, I'm under the impression that I can just use
> > URLClassLoader for that. I think I can construct one of these via JNI
> > and tell it to construct an instance of the vrml.node.Script subclass.
> 
> Right, though I'd suggest extending URLClassLoader with some extras.
> Nothing specific so far, but that's why I mention VRSpaceLoader - it 
> extends URLClassLoader too. As do classloaders of tomcat and others.

I've had a brief look; nothing there jumped out at me as being something
I needed. But I'm still pretty naive about a lot of this. Though it has
occurred to me that if I ever want to do something like display download
progress for this stuff, I'll presumably need to implement my own
URLStreamHandler. Joy.

-- 
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>