Page 1 of 1

thread_default vs prolog_flag

PostPosted: Fri Jun 22, 2007 12:26 am
by tswift
All:

I've been going through the standardization proposal to implement more
of the multi-threading options for XSB. By and large I'm in agreement
with the May 2007 version, but I do have some reservations about
thread_set_default.

I agree that its important to be able to have changeable default
settings -- but it seems like setting aside a group of Prolog flags
for this purpose would work just as well, and in my opinion be more
elegant. I think its nice for users to know that they can alter any
default setting in a system by one or another Prolog flag -- this
makes it easier to find out information when you are new to a system.
Indeed, this is the approach we have taken in XSB for a number of
settable table defaults.

Does anyone have a good argument for using thread_default and
thread_set_default over prolog_flag and set_prolog_flag?

Terry

Re: thread_default vs prolog_flag

PostPosted: Fri Jun 22, 2007 11:25 am
by Paulo Moura
tswift wrote:Does anyone have a good argument for using thread_default and thread_set_default over prolog_flag and set_prolog_flag?


The predicate current_prolog_flag/2, as specified in the ISO standard, requires the first argument (the flag name) to be either an atom or a variable. Being restricted to use atoms for flag names leads to a somehow messy set of flags. E.g. it would be nice to be able to use the term threads(Flag) for all multi-threading related flags. Or arithmetic(Flag) for all arithmetic related flags. In this hypothetical scenario, I would vote for dropping the thread_default/2 and thread_set_default/2 predicates from the proposal. With the current restrictions of flag names to be atoms in current_prolog_flag/2 and set_prolog_flag/2, I'm not so sure. Simple names could easily conflict or be confusing about their meaning. Does stack(Size) refers to Prolog stack size, default thread stack size, or both?

All the best,

Paulo