[m-dev.] Update library pragma C code
Thomas Charles CONWAY
conway at cs.mu.OZ.AU
Mon Aug 3 12:41:15 AEST 1998
Peter Schachte, you write:
> Wouldn't thread_safe be more consistent with Mercury naming standards?
>
I can't remember at the moment which I used...
> > It would be a relatively minor change to add other flags
> > (eg may_need_trailing) or whatever. Of course, getting the compiler to
> > make use of that would be a bigger task.
>
> Indeed it would. My concern was that the infrastructure allow such flags to
> be added.
>
> Is this a backward-compatible change? Ie, when this change is committed,
> will it still be possible to write
>
> pragma c_code(foo(...), will_not_call_mercury, "...")?
If you look at the diff I posted a while ago, it allows both.
>
> One other comment: I think it may be better for the default to be the
> assumption that code does not call Mercury, and to assume that C code does
> no trailing. My reasoning for this is that most foreign code does not trail
> and does not call mercury, and does not use other funny facilities of the
> foreign interface that should perhaps be declared. It should be easy to
> document in the section of the reference manual on calling Mercury from C,
> and in the section on trailing, that if these facilities are used, a special
> flag must be included in the pragma c_code declaration for the function that
> uses that facility. It would be much clumsier, IMHO, to document in the
> section on calling C code from Mercury that users should include the flag
> will_not_call_mercury *unless* the function calls mercury, will_not_trail
> *unless* it does trailing, will_not_muck_something_else_up unless it uses
> the muck_something_else_up facility, etc, particularly when users may not
> know anything about those features.
For safety, the default should be may_call_mercury and not_thread_safe
and may_trail, since if the code may call mercury, may not be thread safe
or may use the trail and the default is the opposite, your code may crash,
but code making the conservative assumption will not.
Thomas
--
Thomas Conway <conway at cs.mu.oz.au>
Nail here [] for new monitor. )O+
More information about the developers
mailing list