Re: Understanding SWI's relationship with a C++ app's working directory.

Jan Wielemaker <[email protected]>
Newsgroups gmane.comp.ai.prolog.swi
Message-ID <[email protected]>
On 03/04/2014 08:43 PM, Kaitain Jones wrote:
>> If nobody messes with it anyway, caching it cannot be a bad idea.
>
> I'm troubled by the fact that I can't set what I am thinking of as being
> the "SWI Prolog WD" without that automatically affecting the WD of the
> entire app, i.e. that there is no concept of a WD just for the SWI
> session (presumably it is too complex and/or time-consuming to use this
> approach). Am I perhaps taking a completely wrong-headed approach by
> setting the WD at all?

I don't know. The WD is (in all OSes I know) a setting of the process
that determines how a not-absolute-file-names are resolved. It can be set
and queried and all parts of the process must maintain a coherent view
of it. There is basically no way to do that in a multi-threaded
environment except for setting the WD while initializing the process and
not touching it afterwards.

SWI-Prolog, once commonly in control of the process, maintains a cached
value of the WD. That is coherent with the above. If the app however
modifies the WD, it must inform SWI-Prolog. If that is infeasible (which
it can be), we have some options. One (as said in my previous mail) is
not to use cached values at all. Another might be to have some setting
that tells Prolog whether or not to use caching.  That depends whether or
not the old motivation to cache this value for performance reasons still
makes as much sense as it did when the caching was added.

Definitely, in a platform independent way, modifying WD in components
of a process and especially in threads is asking for trouble.

	Cheers --- Jan
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.