scm_cell vs threads build option

scm_cell vs threads build option

[Kevin Ryde]

I gave Rob's new debian packaged 1.8.2 a go and found a bit of a problem
with scm_cell.  The new packages have threads enabled, where the old
ones had it disabled, and alas that setting infects the inlined
scm_cell().  If you built your app against the old and run it against
the new then it bombs on SCM_FREELIST_LOC doing the different "thread
key" thingie access.

I guess scm_cell has been inlined that way for a while, but it'd be
worth thinking about not inlining it, or only inlining for internal
uses, in the interests of binary compatibility among as many build
options as possible.

I struck the problem in my own build of guile-gtk, not sure what
packaged stuff might be affected.  gnome-games seems ok.  Anything using
smobs probably isn't.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: scm_cell vs threads build option

[Rob Browning]

Kevin Ryde <user42@zip.com.au> writes:

> I gave Rob's new debian packaged 1.8.2 a go and found a bit of a problem
> with scm_cell.  The new packages have threads enabled, where the old
> ones had it disabled, and alas that setting infects the inlined
> scm_cell().  If you built your app against the old and run it against
> the new then it bombs on SCM_FREELIST_LOC doing the different "thread
> key" thingie access.
>
> I guess scm_cell has been inlined that way for a while, but it'd be
> worth thinking about not inlining it, or only inlining for internal
> uses, in the interests of binary compatibility among as many build
> options as possible.
>
> I struck the problem in my own build of guile-gtk, not sure what
> packaged stuff might be affected.  gnome-games seems ok.  Anything using
> smobs probably isn't.

This is potentially bad (for Debian at least).  I'll have to
investigate, but it may mean that I will have to revert Debian's build
for now so that it doesn't enable threads.

If the library ABIs really aren't binary compatible, then I probably
won't be able to re-enable threads in Debian for 1.8 without some
fairly ugly workaround (parallel packages, or similar).

The problem is that Guile 1.8 in Etch was compiled without threads
(due to some serious problems at the time).  So if there is a binary
incompatibility, then I can't re-enable threads now without breaking
everything in stable (Etch) that was compiled against the non-threaded
version.

Of course, it's generally considered a big mistake to produce two
libraries with the same soname and incompatible binary APIs.  Perhaps
Guile should use a different name for the threaded libs if they're not
compatible.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: scm_cell vs threads build option

[Ludovic Courtès]

Hi,

Rob Browning <rlb@defaultvalue.org> writes:

> This is potentially bad (for Debian at least).  I'll have to
> investigate, but it may mean that I will have to revert Debian's build
> for now so that it doesn't enable threads.

Can't you, for instance, change the Libtool interface number for
`libguile'?  That's ugly, and would require recompilation of all
packages depending on it, but at least it would allow you to produce
thread-enabled packages for the remainder of 1.8.x.

> The problem is that Guile 1.8 in Etch was compiled without threads
> (due to some serious problems at the time).

OTOH, I don't remember seeing any "serious" thread-related bug fix since
1.8.0.  Or did I miss it?

Thanks,
Ludovic.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: scm_cell vs threads build option

[Ludovic Courtès]

Hi,

Kevin Ryde <user42@zip.com.au> writes:

> I guess scm_cell has been inlined that way for a while, but it'd be
> worth thinking about not inlining it, or only inlining for internal
> uses, in the interests of binary compatibility among as many build
> options as possible.

One would have to evaluate the costs associated with this.  On one hand,
this would slow down external packages.  On the other hand, this may
allow us to the `initial-exec' TLS access model (as noted by Andy on
IRC), which can be a significant performance improvement.  What I
dislike is that it would make external packages second-class citizens,
compared to code part of guile-core.

Anyway, that's too late for 1.8 I suppose.

Thanks,
Ludovic.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: scm_cell vs threads build option

[Kevin Ryde]

Rob Browning <rlb@defaultvalue.org> writes:
>
> Perhaps Guile should use a different name for the threaded libs if
> they're not compatible.

I suppose that'd help against mysterious crashes, but leaves the same
problem as in every incompatibility, ie. that add-ons do or don't
switch, making various combinations unusable, or forcing everyone to
recompile in lock-step, etc.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: scm_cell vs threads build option

[Rob Browning]

ludovic.courtes@laas.fr (Ludovic Courtès) writes:

> Can't you, for instance, change the Libtool interface number for
> `libguile'?  That's ugly, and would require recompilation of all
> packages depending on it, but at least it would allow you to produce
> thread-enabled packages for the remainder of 1.8.x.

That doesn't really help unless it's handled officially upstream.
i.e. I believe a given SONAME for a given library name on a given
platform should always produce the exact same ABI.

>> The problem is that Guile 1.8 in Etch was compiled without threads
>> (due to some serious problems at the time).
>
> OTOH, I don't remember seeing any "serious" thread-related bug fix
> since 1.8.0.  Or did I miss it?

If I recall correctly, the problem was that "make check" was failing
when threads were enabled.  I re-enabled threads because it looked
like the problem may have been fixed (perhaps indirectly) in 1.8,.2,
and I wanted to test that in unstable.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel