Subject: Re: SWI-P Win32 port embedding problem

From: Jan Wielemaker <[email-masked]>
Date: Mon, 13 Sep 1999 16:10:43 +0200

[Please break long lines in your posts.  It makes replies much easier!]

On Mon, 06 Sep 1999, Uwe Lesta wrote:
>Petr Kocmid schrieb:
>
>> Another problem I have is with static embedded system. Here is the description:
>> PL_halt() calls Halt() which performs engine cleanup and exit(). 
>> This is not acceptable, since it prevents application to do something
>> meaningfull after prolog engine has been shut. atexit() is not a
>> solution for me, because 1. I need to embed prolog in Win32 GUI app,
>> which opens and closes prolog session by user interaction (AI solver)
>> and 2. want make C++ class wrapper around the engine, where
>> constructor does PL_initialize() and destructor PL_halt()
>> housekeeping.
>
>I initialize prolog in the InitInstance funktion
>and get some memory leaks on ExitInstance.
>It is ugly but works. A better solution is welcome.
>
>> I thing either this exit() call should be moved out of the Halt()
>> to C stub code such as pl-ntcon.c and similars on other platforms or
>> some more portable solution retaining backward compatibility will be
>> perhaps PL_terminate() for embedded system doing only housekeeping or
>> Prolog_exit() with callback setting.

In the current system there is no proper solution to this.  Building
the engine using PL_initialise() is rather expensive, both in terms
of memory and time.  If you do not bother about at_halt or PL_on_halt()
registered hooks, I would simply forget abour calling PL_halt() and
call whatever you like at exit of the program.

My suggestion would be to make one SWI-Prolog engine and refer to that
from multiple C++ objects using a mutex to avoid simultaneous access.

In 3.2.9 there is experimental multi-threading support.  Using that,
PL_initialise() builds the main system, but other functions are there
to create and terminate a Prolog engine in a thread.  These functions
are fairly fast.

Completion (and port to Windows, the current implementation is based on
POSIX threads) is not to expected soon though, as it is not part of some
official project and just evenings now and then.  Help porting to
Windows is appreciated.  Help getting the interfaces right too.  Help
getting it completely implemented is probably hard as a lot of knowledge
of the engine is necesarry to arrive and a suitable low level of locking
using mutexes.

I will consider a shutdown procedure, but it will be hard to reclaim all
associated memory.

	Regards --- Jan