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.
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. :))
--
regards,
bill
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
