--- bill lam <[EMAIL PROTECTED]> wrote: > Oleg Kobchenko wrote: > > J being a shared library has nothing to do with > > ownership of memory, it's the libraries for malloc/free > > that are important. J most probably uses private > > static malloc/free, which means if I assume ownership > > if its memory block and then release it with my > > free, J's memory lib will not know about it. > > I'm confused here, both app and so belong to the same process, the callee can > malloc a memory and pass back the handle to the caller for de-allocation. I > guess that J will malloc a separate block for communication and will not pass > direct pointers to J noun or other objects.
In C runtime library malloc/free use private local heaps which are local to module--not process. So if client code and J DLL both use the same CRT DLL, then it's OK. But I doubt it, especially in Unix, where each application tends to link libraries statically to avoid compatibility issues. To see it in action, in Visual Studio, create a solution with a Console application and a DLL project. Each should use non-DLL Runtime Library in Code Generation setting. Then malloc memory in DLL and free the pointer in application. The debugger will tell you all about invalid heap pointers. > > On a second thought, provided that all naked > > session-related (not engine, but possibly IO) foreign > > conjunction uses are replaced with names, and given > > you have pcall interface, you don't need JSM or Jga. > > That can count as separate use case for pcall. :) > > > > With small exceptions, like 0!:xxx writes directly > > to the mythical output bypassing user API, so there > > is a layer of separation missing. > > From my experience with j socket protocol, > j601/system/extras/help/user/protocol.htm > normally the jfe will call j engine for jDO, but on 3 occasions j engine > needs > to callback the jfe because these functions are implemented by jfe, > 1!:1&1 input > 1!:2&2 output (apparently 1!:1&3 and 1!:2&4 seems done by J engine itself) > 11!:x window driver, > > output to session manager is equivalent to first format ": then 1!:2&2 > > I agree with you that 1!:x family should be replaced by J scripts with direct > api call just as the cases for socket and odbc, may be you could write it for > the J community. :)) I am not sure about direct platform API, because this will mean supporting a lot of different APIs. But shared CRT DLL is a possibility: MSVCRTxx.DLL and libc.so. For example, Python uses MSVCRT DLL for all alloc, files, etc. instead of statically linking, i.e. interfacing HeapAloc, ReadFile directly from kernel32. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
