Subj : Re: JS_THREADSAFE required for clients of threadsafe js32.dll? To : netscape.public.mozilla.jseng From : Justin Fletcher Date : Sun Nov 14 2004 08:50 pm On Wed, 10 Nov 2004, Jens Thiele wrote: > Digital Man schrieb: > > I just noticed that JS_Get/Set/ClearContextThread aren't prototyped in jsapi.h > > unless JS_THREADSAFE is defined. > > > > Now, I've known for a long time that JS_THREADSAFE must be defined when > > building a thread-safe JS library (DLL or SO), but I've never defined this > > macro when building the applications (clients of the JS library). > > > > Must JS_THREADSAFE be defined for applications that #include jsapi.h and use a > > thread-safe JS library? > > yes if the library was compiled with JS_THREADSAFE you must compile your > apps with JS_THREADSAFE, too. The opposite is also true. > > The really bad thing: > JS_GetClass takes either one or two arguments (depending on JS_THREADSAFE) > => the API entry point differs > => you can get really ugly crashs/stack corruption (if you got > JS_THREADSAFE wrong) > I have been caught by this at least twice, too. If this is a problem that is likely to be encountered by users, could it not be made a little safer by the two parts of the system (library and client) checking how they were built. My understanding is that JS_Init is deprecated, JS_NewRuntime is preferred over this, and JS_NewRuntime is provided through a macro. This being the case, the macro might be changed to something akin to... #ifdef JS_THREADSAFE #define JS_NewRuntime(maxbytes) JS_Init(maxbytes, 1) #else #define JS_NewRuntime(maxbytes) JS_Init(maxbytes, 0) #endif with JS_Init being modified to take this additional 'threadsafe' parameter. The JS_Init code could take some action based on whether the threadsafe parameter matched its own known build state. Even if JS_Init could not report the error to the external environment, returning a NULL to indicate that the requested runtime couldn't be created is better than having a seemingly random exception at some later point. Changing the prototype of a core routine like that probably isn't a good idea in an already distributed library, but if the mixing of those two build options is really that bad then is it more useful to have some protection in the library - particularly if the cost of the test is only minimal and only incurred at runtime initialisation ? -- Gerph .... Outside the rain feel dark and slow. .