Jorge, thanks for your quick response. Waiting 8/10 seconds is ok for an user, but not acceptable for an application that is running a service... Building and appending an executable to bind a library, is static linking a module to make "dynamic" calls. What I need is dynamic binding, e.g. loading/unloading without external tools (define calls from upper level of the running system). I am sure it is possible to implement in a vm like V8; I've used (and implemented) the mechanism for other VMs. (I dont want to reinvent any weel, and am asking for references that can help me to do not write code if it is already implemented) At user level the feature is important to implement systems that change and are mantained without restarting (self substained systems). There are implementations where the library name is part of the literal/object that find and execute the native api call; in other implementations the "receiver" of the message is a library instance that perform the target address lookup (contain the libName, to open library once, mantain the handle, find target address, etc). thank you for your time, Ale.
----- Original Message ----- From: Jorge Reyna To: [email protected] Sent: Wednesday, March 30, 2011 11:17 AM Subject: Re: [v8-users] Dynamic bindings (C and API calls) (was: Re: Expanding the language) At this point I'm just starting to play around with v8, not doing anything serious.. so I still don't know how am I going to work when I'll start the real job. I'm working with the real application on Visual Studio 2005, and right now the cycle: write, compile, link, run, has practically no wait states, so it doesn't worry me if it takes 8 or 10 seconds to build the .exe file. I don't know how it is going to behave once I try to embed v8. The package generates a .lib file that takes very long to build for the first time, I don't know how long it will take to build if you change something in the v8 core (since I'm just playing with the samples), however I've noticed that the link process takes a while... so it may be a good idea to assemble a VS project in order to build a set of .dll's instead and link them quickly to the application... but don't know just now... I need to understand first the basic execution flow. I think what you propose is possible, but at this moment I'm not sure how, but if I wanted to do what you just want, my approach (without any deep analysis) would be: create a function let that function handle all the native links with the dll, I mean: the dll load, the dll function call, and finaly handle the returned value... something like this: var rv = externalCall("dll_file_name","function(arguments)" ) Other approach would be to intercept the "undefined identifier" exception so every time this exception rises you check if the exception arose because an undefined function, if so, you then make the link with the dll... not sure at how would you determine the name of the dll... but you could define a standard so every time you wish to make an external call you pass the name of the dll in the first parameter... or perhaps the first 3 characters of the name of the function may be the name of the dll... maybe you can load at stat up an index of functions vs dlls... There maybe other ways to handle the problem, but I can tell right now. -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
