libsigcx-main — Discussion and Development

Re: [Libsigcx-main] You also need libsigc++, which libSigCX is built upon. Note that you ....

[Steven B. <sw...@uc...>]

al va wrote:
> You also need libsigc++, which libSigCX is built upon. Note that you 
> need the at least version 1.1.13.
> 
> I have sigc++2.0 , it's certenly newer then 1.1.13 m but when i run 
> configure script i get and error complaining about sigc version:

sigc++2.0 is a different major version than 1.2, so is probably 
incompatible.  If so, would be nice to see libsigcx updated for it.

[Libsigcx-main] You also need libsigc++, which libSigCX is built upon. Note that you ....

[al v. <va...@ho...>]

You also need libsigc++, which libSigCX is built upon. Note that you need 
the at least version 1.1.13.

I have sigc++2.0 , it's certenly newer then 1.1.13 m but when i run 
configure script i get and error complaining about sigc version:

checking for sigc++-1.2... Package sigc++-1.2 was not found in the 
pkg-config search path.
Perhaps you should add the directory containing `sigc++-1.2.pc'
to the PKG_CONFIG_PATH environment variable
No package 'sigc++-1.2' found

configure: error: Library requirements (sigc++-1.2) not met; consider 
adjusting the PKG_CONFIG_PATH environment variable if your libraries are in 
a nonstandard prefix so pkg-config can find them.


please help me ...

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: [Libsigcx-main] Re: [PATCH] libsigcx-0.6.4 build fixes for Cygwin, older libtools

[Andreas R. <a.r...@gm...>]

Steven Brown <sw...@uc...> writes:

> Andreas Rottmann wrote:
>
>> It seems I know nothing about what undefined sybols in shared
>> libraries are and what they mean. Do you know of any reference? I
>> looked up the --no-undefined ld option, but that didn't explain
>> much. I believe you, however, when you say that -no-undefined cannot
>> hurt and have applied your patch.
>
> As an example, say we have foo.c, bar.c, and main.c as follows:
>
[...]

>
> So, having -no-undefined in is really what 99.9% of folks intend,
> anyway, and is required for some platforms.  I'm really not sure who
> has a need for allowing undefined symbols, but I'd guess it'd be the
> low-level folks like those working on ld-linux.so, maybe the crt0
> stuff, etc..
>
>
Ok, I think I understand now. Thanks a lot for your extended explaination!

Cheers, Rotty
--=20
Andreas Rottmann         | Rotty@ICQ      | 118634484@ICQ | a.rottmann@gmx.=
at
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B=
62
v2sw7MYChw5pr5OFma7u7Lw2m5g/l7Di6e6t5BSb7en6g3/5HZa2Xs6MSr1/2p7 hackerkey.c=
om

Latein ist das humanoide =C3=84quivalent zu Fortran.
   -- Alexander Bartolich in at.linux

Re: [Libsigcx-main] Re: [PATCH] libsigcx-0.6.4 build fixes for Cygwin, older libtools

[Steven B. <sw...@uc...>]

Andreas Rottmann wrote:

> It seems I know nothing about what undefined sybols in shared
> libraries are and what they mean. Do you know of any reference? I
> looked up the --no-undefined ld option, but that didn't explain
> much. I believe you, however, when you say that -no-undefined cannot
> hurt and have applied your patch.

As an example, say we have foo.c, bar.c, and main.c as follows:

swbrown@activecampus:~/tmp/z$ cat foo.c
extern void bar();

void foo() {
   bar();
}

swbrown@activecampus:~/tmp/z$ cat bar.c
void bar() {
}

swbrown@activecampus:~/tmp/z$ cat main.c
extern void foo();

int main() {
   foo();
   return 0;
}

foo.c will be our shared library, main.c will be our application, and 
bar.c will be the shared library foo.c depends on.

We'll build the shared libraries, but not have bar.c available at link 
time, and not use -no-undefined:

swbrown@activecampus:~/tmp/z$ gcc -c bar.c -fPIC -o bar.lo
swbrown@activecampus:~/tmp/z$ ld -shared bar.lo -o bar.so

swbrown@activecampus:~/tmp/z$ gcc -c foo.c -fPIC -o foo.lo
swbrown@activecampus:~/tmp/z$ ld -shared foo.lo -o foo.so

The linker actually let us link foo.so without having any knowledge of 
where the required 'bar' symbol comes from, or if it exists at all.

Now we build main.c and try linking with foo.so:

swbrown@activecampus:~/tmp/z$ gcc -c main.c -o main.o
swbrown@activecampus:~/tmp/z$ gcc main.o foo.so -o main
foo.so: undefined reference to `bar'
collect2: ld returned 1 exit status

Nasty - a link error in a dependency that had sucessfully built.  It's 
almost certainly not what the author of foo.so intended to have happen, 
and is almost certainly a build error that went uncaught.

Now if we had let the linker know about bar.so when we built foo.so, we 
get a much different result:

swbrown@activecampus:~/tmp/z$ ld -shared foo.lo bar.so -o foo.so
swbrown@activecampus:~/tmp/z$ gcc main.o foo.so -o main

And we can verify that it did the right thing (yay GNU, but obviously, 
folks would usually be using libtool for this as not all systems are 
this smart):

swbrown@activecampus:~/tmp/z$ ldd main
         foo.so => foo.so (0xb7fe7000)
         libc.so.6 => /lib/tls/libc.so.6 (0xb7e9e000)
         bar.so => bar.so (0xb7e9c000)
         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb7fea000)

That's probably what the author intended.

Now if we had passed in -no-undefined when we tried to build foo.so the 
wrong way:

swbrown@activecampus:~/tmp/z$ ld -shared -no-undefined foo.lo -o foo.so
foo.lo(.text+0x13): In function `foo':
: undefined reference to `bar'

The error was caught when building foo.so rather than building anything 
using foo.so.  That's a much better situation, especially when you've 
got a symbol mangling bug in C++ - you wind up bald debugging those, 
that is, if your terminal ever stops scrolling. ;)

Note though, that it has no issue with symbols that are defined in 
another library it knew about at link time:

swbrown@activecampus:~/tmp/z$ ld -shared -no-undefined foo.lo bar.so -o 
foo.so

swbrown@activecampus:~/tmp/z$ ldd foo.so
         bar.so => bar.so (0xb7ffb000)


So, having -no-undefined in is really what 99.9% of folks intend, 
anyway, and is required for some platforms.  I'm really not sure who has 
a need for allowing undefined symbols, but I'd guess it'd be the 
low-level folks like those working on ld-linux.so, maybe the crt0 stuff, 
etc..

[Libsigcx-main] Re: [PATCH] libsigcx-0.6.4 build fixes for Cygwin, older libtools

[Steven B. <sw...@uc...>]

Andreas Rottmann wrote:

> I've switched away from CVS some time ago. The current version of
> libsigcx is in my GNU Arch archive[0]. I should probably wipe out CVS
> and put a pointer to the Arch archive in there.
> 
> [0] http://yi.org/rotty/Software#gnuarch
> 
> FYI, am not *actively* developing libsigcx anymore, but patches are
> always welcome.

No prob., I have some stuff that moves at the speed of patches as well. :)

You already seem to have fixed the libtool.m4 issue in the arch tree, 
and the version of one of the libs changed, so I've updated the patch to 
work against the current arch tree and attached it.  The result builds 
out of the box on Cygwin, Debian Woody, and Debian Sarge, and passes check.

>>ChangeLog from the attached patch:
> 
> [...]
> 
>>	* sigcx/Makefile.am: Add -no-undefined to the LDFLAGS of the
>>	shared libraries as Windows DLLs can't deal with undefined
>>	symbols - sigcx doesn't depend on having them, anyway.
>>
> I'm not sure about this one; I know that -no-undefined is needed for
> MinGW and Cygwin, but do you have any reference that explains why it
> doesn't hurt on other platforms?

As long as the resulting library doesn't require undefined symbols, it's 
not a problem.  -no-undefined basically just asserts that you know your 
code doesn't require that feature (I can't even think of a library that 
does actually require it - maybe ld-linux.so?).  I assume it's only for 
legacy reasons that it's not on by default and there'd be a "-undefined" 
flag instead.  Without it, it would let you successfully build a shared 
lib that the toolchain knew couldn't ever be linked to anything without 
additional help from the user.

Last I remembered, -no-undefined was unfortunately treated as a NOOP on 
Linux which would result in not catching some build errors until you 
tried using the shared lib, but I ran into this while looking:

http://lists.gnu.org/archive/html/libtool-patches/2003-06/msg00023.html

It might have finally made it into libtool in the 1.5 branch.

[Libsigcx-main] Re: [PATCH] libsigcx-0.6.4 build fixes for Cygwin, older libtools

[Andreas R. <a.r...@gm...>]

Steven Brown <sw...@uc...> writes:

> Hello, I've made a few fixes to libsigcx-0.6.4 to get it building on
> Cygwin with shared libraries (DLLs), and from CVS with older libtools
> (E.g., on Debian Woody).  Seems pretty healthy - can this get added to
> CVS?  
>
I've switched away from CVS some time ago. The current version of
libsigcx is in my GNU Arch archive[0]. I should probably wipe out CVS
and put a pointer to the Arch archive in there.

[0] http://yi.org/rotty/Software#gnuarch

FYI, am not *actively* developing libsigcx anymore, but patches are
always welcome.

> ChangeLog from the attached patch:
>
[...]
> 	* sigcx/Makefile.am: Add -no-undefined to the LDFLAGS of the
> 	shared libraries as Windows DLLs can't deal with undefined
> 	symbols - sigcx doesn't depend on having them, anyway.
>
I'm not sure about this one; I know that -no-undefined is needed for
MinGW and Cygwin, but do you have any reference that explains why it
doesn't hurt on other platforms?

Other than that, the patch looks good. Thanks!

Regards, Rotty
-- 
Andreas Rottmann         | Rotty@ICQ      | 118634484@ICQ | a.r...@gm...
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62
v2sw7MYChw5pr5OFma7u7Lw2m5g/l7Di6e6t5BSb7en6g3/5HZa2Xs6MSr1/2p7 hackerkey.com

A. Because it breaks the logical sequence of discussion
Q. Why is top posting bad?

Re: [Libsigcx-main] Is sigcx development stalled?

[Andreas R. <a.r...@gm...>]

Angus Leeming <le...@ly...> writes:

> Hi Andreas,
>
> I have just downloaded libsigcx, both the branch_release-0_6 version 
> and current HEAD
>
> $ cvs -d:pserver:ano...@cv...:/cvsroot/libsigcx co -r 
> branch_release-0_6 -d 0.6 sigcx
> $ cvs -d:pserver:ano...@cv...:/cvsroot/libsigcx co -d 
> devel sigcx 
>
> but can compile neither version. Compilation fails in identical 
> fashion to that reported on the sigcx mailing list by Peter Gasper on 
> 26 Oct (and for the same reason --- I'm using g++ 3.4):
>
> compile error on mandrake 10.1 community
> Peter Gasper <pgasper@de...>
>
>  ../sigcx/tunnel.h:223: error: no matching function for call to 
>  `pack(SigC::Slot1<bool, const std::string&>&, const 
>  std::basic_string<char, std::char_traits<char>, 
> std::allocator<char>>&)"
>  
> It seems that this was the last message posted to the list.
>
> So, the question: should I investigate sigcx further? Is the project 
> dead? Has it been moved elsewhere?
>
The project is more or less dead[0] - the last release being the point to
pick the project off, if anyone feels like that.

[0] I've not done much C++ programming lately, as I feel more
    compelled by Scheme
-- 
Andreas Rottmann         | Rotty@ICQ      | 118634484@ICQ | a.r...@gm...
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Make free software, not war!

[Libsigcx-main] Is sigcx development stalled?

[Angus L. <le...@ly...>]

Hi Andreas,

I have just downloaded libsigcx, both the branch_release-0_6 version 
and current HEAD

$ cvs -d:pserver:ano...@cv...:/cvsroot/libsigcx co -r 
branch_release-0_6 -d 0.6 sigcx
$ cvs -d:pserver:ano...@cv...:/cvsroot/libsigcx co -d 
devel sigcx 

but can compile neither version. Compilation fails in identical 
fashion to that reported on the sigcx mailing list by Peter Gasper on 
26 Oct (and for the same reason --- I'm using g++ 3.4):

compile error on mandrake 10.1 community
Peter Gasper <pgasper@de...>

 ../sigcx/tunnel.h:223: error: no matching function for call to 
 `pack(SigC::Slot1<bool, const std::string&>&, const 
 std::basic_string<char, std::char_traits<char>, 
std::allocator<char>>&)"
 
It seems that this was the last message posted to the list.

So, the question: should I investigate sigcx further? Is the project 
dead? Has it been moved elsewhere?

Please advise.
Regards,
Angus

Re: [Libsigcx-main] compile error on mandrake 10.1 community

[Andreas R. <a.r...@gm...>]

Peter Gasper <pg...@de...> writes:

> I am trying to compile libsigcx-0.6.4 on Mandrake 10.1
> Community. Something is failing in the first test compile, I'm not
> sure what the problem is.  I get the following error during make after
> ./configure (or ./configure --with-gtk):
>
> make[2]: Entering directory
> `/home/pgasper/lbproject/developement_software/libsigcx-0.6.4/tests'
> if g++ -DHAVE_CONFIG_H -I. -I. -I..
> -I.. -I/usr/lib/sigc++-1.2/include -I/usr/include/sigc++-1.2
> -D_REENTRANT   -Wall -O2 -MT x_thread_test.o -MD -MP -MF
> ".deps/x_thread_test.Tpo" \
>   -c -o x_thread_test.o `test -f 'x_thread_test.cc' || echo
> './'`x_thread_test.cc; \
> then mv -f ".deps/x_thread_test.Tpo" ".deps/x_thread_test.Po"; \
> else rm -f ".deps/x_thread_test.Tpo"; exit 1; \
> fi
> ../sigcx/tunnel.h: In static member function `static R
> SigCX::TunnelCallback1<R, P1>::pack_n_tunnel(P1, SigC::Slot1<R, P1>,
> SigCX::Tunnel*, bool) [with R = bool, P1 = const std::string&]':
> ../sigcx/tunnel.h:288:   instantiated from `R
> SigCX::tunnel(SigC::Slot1<R, P1>, P1, SigCX::Tunnel*, bool) [with R =
> bool, P1 = const std::string&]'
> x_thread_test.cc:107:   instantiated from here
> ../sigcx/tunnel.h:223: error: no matching function for call to
> `pack(SigC::Slot1<bool, const std::string&>&, const
> std::basic_string<char, std::char_traits<char>, std::allocator<char>
>>&)'
> make[2]: *** [x_thread_test.o] Error 1
> make[2]: Leaving directory
> `/home/pgasper/lbproject/developement_software/libsigcx-0.6.4/tests'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory
> `/home/pgasper/lbproject/developement_software/libsigcx-0.6.4'
> make: *** [all] Error 2
>
>
>
> RPM's installed on this system are: gtk+ 2.4.9, gtkmm 2.2.12,
> libsigc++ 1.2.5, gcc 3.4.1-4, libstdc++6 3.4.1.
>
Well, I can reproduce this with g++ 3.4. Looking at the source, I can
find no abovious solution how to fix this (and I'm not sure why 3.4
barfs at the code), so please try with g++ 3.3 in the meantime.

Regards, Rotty
-- 
Andreas Rottmann         | Rotty@ICQ      | 118634484@ICQ | a.r...@gm...
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

I have a truly elegant proof of the  above, but it is too long to
fit into this .signature file.

[Libsigcx-main] compile error on mandrake 10.1 community

[Peter G. <pg...@de...>]

I am trying to compile libsigcx-0.6.4 on Mandrake 10.1 Community. 
Something is failing in the first test compile, I'm not sure what the 
problem is.  I get the following error during make after ./configure (or 
./configure --with-gtk):

make[2]: Entering directory 
`/home/pgasper/lbproject/developement_software/libsigcx-0.6.4/tests'
if g++ -DHAVE_CONFIG_H -I. -I. -I..  -I.. -I/usr/lib/sigc++-1.2/include 
-I/usr/include/sigc++-1.2   -D_REENTRANT   -Wall -O2 -MT x_thread_test.o 
-MD -MP -MF ".deps/x_thread_test.Tpo" \
  -c -o x_thread_test.o `test -f 'x_thread_test.cc' || echo 
'./'`x_thread_test.cc; \
then mv -f ".deps/x_thread_test.Tpo" ".deps/x_thread_test.Po"; \
else rm -f ".deps/x_thread_test.Tpo"; exit 1; \
fi
../sigcx/tunnel.h: In static member function `static R 
SigCX::TunnelCallback1<R, P1>::pack_n_tunnel(P1, SigC::Slot1<R, P1>, 
SigCX::Tunnel*, bool) [with R = bool, P1 = const std::string&]':
../sigcx/tunnel.h:288:   instantiated from `R 
SigCX::tunnel(SigC::Slot1<R, P1>, P1, SigCX::Tunnel*, bool) [with R = 
bool, P1 = const std::string&]'
x_thread_test.cc:107:   instantiated from here
../sigcx/tunnel.h:223: error: no matching function for call to 
`pack(SigC::Slot1<bool, const std::string&>&, const 
std::basic_string<char, std::char_traits<char>, std::allocator<char> >&)'
make[2]: *** [x_thread_test.o] Error 1
make[2]: Leaving directory 
`/home/pgasper/lbproject/developement_software/libsigcx-0.6.4/tests'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory 
`/home/pgasper/lbproject/developement_software/libsigcx-0.6.4'
make: *** [all] Error 2



RPM's installed on this system are: gtk+ 2.4.9, gtkmm 2.2.12, libsigc++ 
1.2.5, gcc 3.4.1-4, libstdc++6 3.4.1.

Thank you for your help,

Pete Gasper

[Libsigcx-main] compile error (mingw32)

[Jason H. (6. 592-1. <he...@ra...>]

Hi does libsigcx work for microsoft windows setups?  I have gtkmm setup 
with the mingw32 compiler but these are the error messages for libsigcx:

$ make
make  all-recursive
make[1]: Entering directory `/c/unzipped/libsigcx-0.6.2'
Making all in sigcx
make[2]: Entering directory `/c/unzipped/libsigcx-0.6.2/sigcx'
make  all-recursive
make[3]: Entering directory `/c/unzipped/libsigcx-0.6.2/sigcx'
Making all in macros
make[4]: Entering directory `/c/unzipped/libsigcx-0.6.2/sigcx/macros'
make[4]: Nothing to be done for `all'.
make[4]: Leaving directory `/c/unzipped/libsigcx-0.6.2/sigcx/macros'
make[4]: Entering directory `/c/unzipped/libsigcx-0.6.2/sigcx'
if /bin/sh ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I.. 
-I.. -IC:/gtkmm/include/sigc++-2.0 -IC:/gtkmm/lib/sigc++-2.0/include   
-D_REENTRANT -IC:/GTK/include/gtk-2.0 -IC:/GTK/lib/gtk-2.0/include 
-IC:/GTK/include/atk-1.0 -IC:/GTK/include/pango-1.0 
-IC:/GTK/include/glib-2.0 -IC:/GTK/lib/glib-2.0/include      -Wall -O2 
-MT util.lo -MD -MP -MF ".deps/util.Tpo" \
  -c -o util.lo `test -f 'util.cc' || echo './'`util.cc; \
then mv ".deps/util.Tpo" ".deps/util.Plo"; \
else rm -f ".deps/util.Tpo"; exit 1; \
fi
g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -IC:/gtkmm/include/sigc++-2.0 
-IC:/gtkmm/lib/sigc++-2.0/include -D_REENTRANT -IC:/GTK/include/gtk-2.0 
-IC:/GTK/lib/gtk-2.0/include -IC:/GTK/include/atk-1.0 
-IC:/GTK/include/pango-1.0 -IC:/GTK/include/glib-2.0 
-IC:/GTK/lib/glib-2.0/include -Wall -O2 -MT util.lo -MD -MP -MF 
.deps/util.Tpo -c util.cc  -DDLL_EXPORT -DPIC -o util.lo
if /bin/sh ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I.. 
-I.. -IC:/gtkmm/include/sigc++-2.0 -IC:/gtkmm/lib/sigc++-2.0/include   
-D_REENTRANT -IC:/GTK/include/gtk-2.0 -IC:/GTK/lib/gtk-2.0/include 
-IC:/GTK/include/atk-1.0 -IC:/GTK/include/pango-1.0 
-IC:/GTK/include/glib-2.0 -IC:/GTK/lib/glib-2.0/include      -Wall -O2 
-MT timeval.lo -MD -MP -MF ".deps/timeval.Tpo" \
  -c -o timeval.lo `test -f 'timeval.cc' || echo './'`timeval.cc; \
then mv ".deps/timeval.Tpo" ".deps/timeval.Plo"; \
else rm -f ".deps/timeval.Tpo"; exit 1; \
fi
g++ -DHAVE_CONFIG_H -I. -I. -I.. -I.. -IC:/gtkmm/include/sigc++-2.0 
-IC:/gtkmm/lib/sigc++-2.0/include -D_REENTRANT -IC:/GTK/include/gtk-2.0 
-IC:/GTK/lib/gtk-2.0/include -IC:/GTK/include/atk-1.0 
-IC:/GTK/include/pango-1.0 -IC:/GTK/include/glib-2.0 
-IC:/GTK/lib/glib-2.0/include -Wall -O2 -MT timeval.lo -MD -MP -MF 
.deps/timeval.Tpo -c timeval.cc  -DDLL_EXPORT -DPIC -o timeval.lo
timeval.cc: In member function `void SigCX::TimeVal::get_current_time()':
timeval.cc:39: `gettimeofday' undeclared (first use this function)
timeval.cc:39: (Each undeclared identifier is reported only once for each
   function it appears in.)
make[4]: *** [timeval.lo] Error 1
make[4]: Leaving directory `/c/unzipped/libsigcx-0.6.2/sigcx'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/c/unzipped/libsigcx-0.6.2/sigcx'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/c/unzipped/libsigcx-0.6.2/sigcx'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/c/unzipped/libsigcx-0.6.2'
make: *** [all] Error 2

Re: [Libsigcx-main] bug in GtkDispatcher::timer_callback()

[Andreas R. <a.r...@gm...>]

klaus triendl <tri...@ao...> writes:

> ----- Original von:  Andreas Rottmann <a.r...@gm...>:
>> > "Klaus Triendl" <tri...@ao...> writes:
>> > hi,
>> >
>> > while testing timeouting handlers in GtkDispatcher i found a bug
>> > (version  0.6.4):
>> >
>> > in file gtk_dispatch.cc, line 50, the event (with its callback) is
>> > erased  from the map, but the callback is called a few lines later -
>> > the handler  gets never called because the slot object is not valid
>> > anymore.
>> >
>> When you move the callback invocation before the removal loop code, does it work then?
>> 
>> Cheers & Thanks,
>>        Rotty
>
> yes, it works then; what i did was assigning the callback to a local
> copy which i called at the end of the method.
>
> can you please tell me when you release a new version (debian
> package)? because then i would make my program dependant on that new
> package version.
>
You can subscribe the PTS for libsigcx, see
http://packages.qa.debian.org/libs/libsigcx.html. I think you should
get email notification with new uploads then.

Regards, Rotty
-- 
Andreas Rottmann         | Rotty@ICQ      | 118634484@ICQ | a.r...@gm...
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Software Patents: Where do you want to stifle inovation today?

Re: [Libsigcx-main] bug in GtkDispatcher::timer_callback()

[klaus t. <tri...@ao...>]

----- Original von:  Andreas Rottmann <a.r...@gm...>:
> > "Klaus Triendl" <tri...@ao...> writes:
> > hi,
> >
> > while testing timeouting handlers in GtkDispatcher i found a bug
> > (version  0.6.4):
> >
> > in file gtk_dispatch.cc, line 50, the event (with its callback) is
> > erased  from the map, but the callback is called a few lines later -
> > the handler  gets never called because the slot object is not valid
> > anymore.
> >
> When you move the callback invocation before the removal loop code, does it work then?
> 
> Cheers & Thanks,
>        Rotty

yes, it works then;
what i did was assigning the callback to a local copy which i called at the end of the method.

can you please tell me when you release a new version (debian package)? because then i would make my program dependant on that new package version.

thx!

--
http://triendl.info
klaus triendl


-------------------------------------------
Versendet durch AonWebmail (webmail.aon.at)

Re: [Libsigcx-main] bug in GtkDispatcher::timer_callback()

[Andreas R. <a.r...@gm...>]

"Klaus Triendl" <tri...@ao...> writes:

> hi,
>
> while testing timeouting handlers in GtkDispatcher i found a bug
> (version  0.6.4):
>
> in file gtk_dispatch.cc, line 50, the event (with its callback) is
> erased  from the map, but the callback is called a few lines later -
> the handler  gets never called because the slot object is not valid
> anymore.
>
When you move the callback invocation before the removal loop code,
does it work then?

Cheers & Thanks,
       Rotty
-- 
Andreas Rottmann         | Rotty@ICQ      | 118634484@ICQ | a.r...@gm...
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Say NO to Software Patents! -- http://petition.eurolinux.org/

[Libsigcx-main] bug in GtkDispatcher::timer_callback()

[Klaus T. <tri...@ao...>]

hi,

while testing timeouting handlers in GtkDispatcher i found a bug (version  
0.6.4):

in file gtk_dispatch.cc, line 50, the event (with its callback) is erased  
 from the map, but the callback is called a few lines later - the handler  
gets never called because the slot object is not valid anymore.

--
http://triendl.info
klaus triendl

[Libsigcx-main] Re: [sigc] Re: [gtkmm] libsigcx and gtkmm 2.4

[Martin S. <mar...@hi...>]

Here is an interesting article related to this thread:

http://en.wikipedia.org/wiki/Lock-free_and_wait-free_algorithms

-- Martin

Am 15.06.2004 09:58:41 schrieb(en) Martin Schulze:
> Am 14.06.2004 19:34:41 schrieb(en) Christer Palm:
>> Daniel Elstner wrote:
>>> 
>>> Okay, you're (partly) right.  ("Partly" because it's not "locking  
>>> or
>>> unlocking": what's needed is unlock in thread A and lock in thread  
>>> B.)
>>> I found this in Butenhof:
>>> 
>>>         Whatever memory values a thread can see when it unlocks a  
>>> mutex,
>>>         either directly or by waiting on a condition variable, can  
>>> also
>>>         be seen by any thread that later locks the same mutex.   
>>> Again,
>>>         data written after the mutex is unlocked may not  
>>> necessarily be
>>>         seen by the thread that locks the mutex, even if the write
>>>         occurs before the lock.
>>> 
>>> In other words, the sequence
>>> 
>>>         pthread_mutex_lock(mutex);
>>>         pthread_mutex_unlock(mutex);
>>> 
>>> issues a memory barrier instruction on the unlock.  The other  
>>> thread
>>> that wants to read the data still has to lock the same mutex  
>>> though.
>>>
>> 
>> A memory barrier, or synchronize, instruction is issued both on lock  
>> and unlock and also in a bunch of other thread related functions. Of  
>> course all threads need to agree on which mutex protects memory  
>> location X, that's how they make sure they doesn't execute a region  
>> of code that access memory location X simultaneously. Not because  
>> only certain memory locations are syncronized then the mutex is  
>> locked/unlocked.
>> 
>> Having said that, is there any place in mine or Martins code where  
>> you believe that this rule isn't followed, except as a side effect  
>> of passing objects that contain internal references?
>> 
>> 
>> This is what IEEE Std 1003.1-2004 has to say about memory  
>> synchronization requirements:
>> 
>>  4.10 Memory Synchronization
>> 
>> Applications shall ensure that access to any memory location by more  
>> than one thread of control (threads or processes) is restricted such  
>> that no thread of control can read or modify a memory location while  
>> another thread of control may be modifying it. Such access is  
>> restricted using functions that synchronize thread execution and  
>> also synchronize memory with respect to other threads. The following  
>> functions synchronize memory with respect to other threads:
>> 
>> ...
>> pthread_mutex_lock()
>> ...
>> pthread_mutex_unlock()
>> ...
> 
> This gives rise to an interesting question: If no locking is required  
> (e.g. because atomic operations are used), which is the most  
> efficient call to establish a memory barrier (e.g. before doing the  
> atomic operation)? In a linux driver, I would call wmb(), but what  
> can I do on the application side? Signal a dummy condition?
> 
> Regards,
> 
>  Martin
> _______________________________________________
> gtkmm-list mailing list
> gtk...@gn...
> http://mail.gnome.org/mailman/listinfo/gtkmm-list

[Libsigcx-main] Re: [sigc] Re: [gtkmm] libsigcx and gtkmm 2.4

[Christer P. <pa...@no...>]

Martin Schulze wrote:
> 
> This gives rise to an interesting question: If no locking is required  
> (e.g. because atomic operations are used), which is the most efficient  
> call to establish a memory barrier (e.g. before doing the atomic  
> operation)? In a linux driver, I would call wmb(), but what can I do on  
> the application side? Signal a dummy condition?
> 

I'm pretty sure there isn't a portable way of doing that without 
locking. Even if threads agree on memory contents at the actual point of 
syncronization, they will not stay syncronized for long. The atomic 
operation needs to run within the scope of syncronization, and the 
mechanism to implement that is architecture dependent.

It shouldn't really matter, though, as there's no portable way of 
issuing an atomic operation either. At least not in C/C++.

--
Christer Palm

[Libsigcx-main] Re: [sigc] Re: [gtkmm] libsigcx and gtkmm 2.4

[Martin S. <mar...@hi...>]

Am 14.06.2004 19:34:41 schrieb(en) Christer Palm:
> Daniel Elstner wrote:
>> 
>> Okay, you're (partly) right.  ("Partly" because it's not "locking or
>> unlocking": what's needed is unlock in thread A and lock in thread  
>> B.)
>> I found this in Butenhof:
>> 
>>         Whatever memory values a thread can see when it unlocks a  
>> mutex,
>>         either directly or by waiting on a condition variable, can  
>> also
>>         be seen by any thread that later locks the same mutex.   
>> Again,
>>         data written after the mutex is unlocked may not necessarily  
>> be
>>         seen by the thread that locks the mutex, even if the write
>>         occurs before the lock.
>> 
>> In other words, the sequence
>> 
>>         pthread_mutex_lock(mutex);
>>         pthread_mutex_unlock(mutex);
>> 
>> issues a memory barrier instruction on the unlock.  The other thread
>> that wants to read the data still has to lock the same mutex though.
>>
> 
> A memory barrier, or synchronize, instruction is issued both on lock  
> and unlock and also in a bunch of other thread related functions. Of  
> course all threads need to agree on which mutex protects memory  
> location X, that's how they make sure they doesn't execute a region  
> of code that access memory location X simultaneously. Not because  
> only certain memory locations are syncronized then the mutex is  
> locked/unlocked.
> 
> Having said that, is there any place in mine or Martins code where  
> you believe that this rule isn't followed, except as a side effect of  
> passing objects that contain internal references?
> 
> 
> This is what IEEE Std 1003.1-2004 has to say about memory  
> synchronization requirements:
> 
>  4.10 Memory Synchronization
> 
> Applications shall ensure that access to any memory location by more  
> than one thread of control (threads or processes) is restricted such  
> that no thread of control can read or modify a memory location while  
> another thread of control may be modifying it. Such access is  
> restricted using functions that synchronize thread execution and also  
> synchronize memory with respect to other threads. The following  
> functions synchronize memory with respect to other threads:
> 
> ...
> pthread_mutex_lock()
> ...
> pthread_mutex_unlock()
> ...

This gives rise to an interesting question: If no locking is required  
(e.g. because atomic operations are used), which is the most efficient  
call to establish a memory barrier (e.g. before doing the atomic  
operation)? In a linux driver, I would call wmb(), but what can I do on  
the application side? Signal a dummy condition?

Regards,

  Martin

[Libsigcx-main] Re: [sigc] Re: [gtkmm] libsigcx and gtkmm 2.4

[Daniel E. <dan...@gm...>]

Am So, den 13.06.2004 um 12:47 Uhr -0700 schrieb Timothy M. Shead:

> Can't comment on the threading-specific issues raised in this argument, 
> but I do have to correct this common misperception that C++ doesn't have 
> serialization - it most certainly does, using the OO, type-safe 
> iostreams interface.  See boost::lexical_cast for a 
> trivial-but-effective tool for putting those serialization capabilities 
> to work.

Cool, didn't think about that.  Although this would still require
operator<< and operator>> to be implemented, it's a much nicer
interface.

The only problem would be that it's unnecessarily inefficient for data
types that can simply be copied "as is" without converting to a text
representation and back again.  But perhaps that's acceptable.

--Daniel

[Libsigcx-main] Re: [sigc] Re: [gtkmm] libsigcx and gtkmm 2.4

[Christer P. <pa...@no...>]

Timothy M. Shead wrote:
> 
> Can't comment on the threading-specific issues raised in this argument, 
> but I do have to correct this common misperception that C++ doesn't have 
> serialization - it most certainly does, using the OO, type-safe 
> iostreams interface.  See boost::lexical_cast for a 
> trivial-but-effective tool for putting those serialization capabilities 
> to work.
> 

Sorry, but I meant a useful form of serialization... Something that can 
serialize pretty much any object or at least works with the classes 
provided by the standard library. Beeing able to deserialize the result 
would also be nice.

--
Christer Palm

[Libsigcx-main] Re: [sigc] Re: [gtkmm] libsigcx and gtkmm 2.4

[Martin S. <mar...@hi...>]

Am 13.06.2004 00:03:36 schrieb(en) Daniel Elstner:
> Am Sa, den 12.06.2004 um 15:19 Uhr +0200 schrieb Christer Palm:
> 
> > Thanks Martin!
> >
> > I "stole" the basic principles from your class to create my own
> variant
> > of a multi-argument Gtk::Dispatcher. As I think this is some pretty
> > useful stuff, I'm posting the result here.
> >
> > Perhaps this could be adapted to go into the Glibmm distribution?
> > Let me all know what you think.
> 
> The problem is that I'm still not convinced that cross-thread
> signalling
> with arguments can be implemented correctly as a generic template.
> From
> Martin's description of the SigCX solution it appears that a so- 
> called
> synchronous mode is used to get around that:

The synchronous mode can optionally be used if the execution of the  
calling thread should be suspended until the dispatcher has handled the  
signal. It is not intended to be used as a work-around; asynchronous  
mode should always work.

> 
>       disp.tunnel(sigc::bind(&foo, std::string("hello world")));
>       /*
>          - call this function from any thread;
>          - bind up to 7 arguments at once
>          - pass 'true' as a second argument if the slot should
>            be executed synchronously;
>          - make use of signal::make_slot() if the dispatcher
>            should emit a signal;
>        */
> 
> Hmm std::string is a perfect example of an argument type that  
> requires
> special handling.

Why? The slot object is completely initialized before the dispatcher  
knows of it. Note that sigc::bind does not take arguments as references  
by default if this is where you are heading.

> So assuming "synchronously" does what I think it
> does, why doesn't the example use this mode?
> 
> How does this synchronous thing work?  Does it really wait for the
> main
> loop to process the signal, and wouldn't that defeat the purpose of
> threads?

Yes it does, and well, I have no use the synchronous mode currently.

>  Even if it does this you still need mutex locking to protect
> the memory being shared (ensuring that event A happens after event B
> is
> not enough due to the way modern hardware works; you definitely need
> memory barriers too).

Why would you need memory barries? Thread A creates some objects,  
thread B (the dispatcher) uses them and destroys them afterwards.
Of course, if you pass references around, you need to make sure that  
thread A doesn't manipulate the data while thread B is handling it,  
yourself.

Regards,

  Martin



> 
> Also, you can always use plain Glib::Dispatcher in conjunction with a
> Glib::Mutex to pass data around.  This way you're forced to think
> about
> the locking which is IMHO a good thing.
> 
> When I thought about adding signal parameter support to
> Glib::Dispatcher
> a while ago, I played with the idea of making Glib::Dispatcher  
> provide
> a
> low-level interface for sending raw blocks of memory through the  
> pipe.
> On top of that there could be some kind of plugin interface that
> requires you to implement two functions that convert your data to raw
> memory and back again.  I don't think it should be entirely automagic
> through templates since that'd give the user a false sense of
> security.
> The big advantage of course is avoidance of any locking whatsoever.
> 
> Comments, corrections, insights, etc. will be appreciated.
> 
> Cheers,
> --Daniel
> 
> 
> 

[Libsigcx-main] Re: [sigc] Re: [gtkmm] libsigcx and gtkmm 2.4

[Martin S. <mar...@hi...>]

Am 13.06.2004 16:33:45 schrieb(en) Daniel Elstner:
> Am So, den 13.06.2004 um 2:10 Uhr +0200 schrieb Martin Schulze:
> > >
> > > Hmm std::string is a perfect example of an argument type that
> > > requires
> > > special handling.
> >
> > Why? The slot object is completely initialized before the  
> dispatcher
> 
> > knows of it. Note that sigc::bind does not take arguments as
> references
> > by default if this is where you are heading.
> 
> std::string can be implemented with reference counting, and the
> libstdc++ shipped with GCC does exactly that.

Meaning that no deep copy of the string is made although it is passed  
"by value"?! Then I understand the problem here.
(However, if you pass a "const char*" into the std::string ctor as in  
my example the copy is being created at once, isn't it?)

> > >  Even if it does this you still need mutex locking to protect
> > > the memory being shared (ensuring that event A happens after  
> event
> B
> > > is
> > > not enough due to the way modern hardware works; you definitely
> need
> > > memory barriers too).
> >
> > Why would you need memory barries? Thread A creates some objects,
> > thread B (the dispatcher) uses them and destroys them afterwards.
> > Of course, if you pass references around, you need to make sure  
> that
> 
> > thread A doesn't manipulate the data while thread B is handling it,
> 
> > yourself.
> 
> Wrong!  It's not that simple.  Whenever two threads access the same
> data, both have to acquire the same mutex for any access to it
> whatsoever, be it reading or writing.  The only situation where this
> rule doesn't apply is if thread A creates the data before launching
> thread B, and both threads never write to it again, or only thread B
> does and thread A never accesses it at all.
> 
> I highly recommend reading Butenhof's Programming with POSIX Threads.
> In particular, memorize Chapter 3.4 Memory visibility between  
> threads.
> 
> Here's a table from that chapter:
> 
> Time	Thread 1			Thread 2
> -----------------------------------------------------------------
> t	write "1" to address 1 (cache)
> t+1	write "2" to address 2 (cache)	read "0" from address
> 1
> t+2	cache system flushes address 2
> t+3					read "2" from address 2
> t+4	cache system flushes address 1
> 
> The point here is that there are no guarantees about memory ordering
> whatsoever.  As it happens reading address 2 works by chance, but the
> read from address 1 returns the wrong value despite the fact that the
> read happens after the write was completed.
> 
> Usage of special instructions is required to guarantee ordering,
> called
> "memory barriers".  Locking/unlocking a mutex issues these
> instructions.

I still don't see the problem in the case where no references/pointers  
are being passed around: The list of slots the dispatcher operates on  
_is_ protected by memory barriers (there might be bugs in my code but  
it is perfectly possible to simply use a mutex around 'std::list:: 
push_back()' / 'std::list::pop_front()' as I pointed out in a comment  
and as Christer does).

Regards,

  Martin

[Libsigcx-main] Re: [sigc] Re: [gtkmm] libsigcx and gtkmm 2.4

[Martin S. <mar...@hi...>]

Am 13.06.2004 19:45:57 schrieb(en) Daniel Elstner:
> Am So, den 13.06.2004 um 18:30 Uhr +0200 schrieb Martin Schulze:
> > >
> > > > knows of it. Note that sigc::bind does not take arguments as
> > > references
> > > > by default if this is where you are heading.
> > >
> > > std::string can be implemented with reference counting, and the
> > > libstdc++ shipped with GCC does exactly that.
> >
> > Meaning that no deep copy of the string is made although it is
> passed
> > "by value"?! Then I understand the problem here.
> 
> Exactly.
> 
> > (However, if you pass a "const char*" into the std::string ctor as
> in
> > my example the copy is being created at once, isn't it?)
> 
> Right.  But you have to lock *before* creating the std::string  
> object!
> 
> > I still don't see the problem in the case where no
> references/pointers
> > are being passed around: The list of slots the dispatcher operates
> on
> > _is_ protected by memory barriers (there might be bugs in my code
> but
> > it is perfectly possible to simply use a mutex around 'std::list::
> > push_back()' / 'std::list::pop_front()' as I pointed out in a
> comment
> > and as Christer does).
> 
> Sure, but the caller passes in an already constructed std::string.   
> As
> I
> said above, you need to lock before constructing the object.

Sorry, I'm a bit lame at the moment. I'm trying to express the problem  
in a simple flow table with a *bang* at time=t+4:


time    thread A should do (*does)               thread B [*does]
-------------------------------------------------------------------
t       construct slot
                    (*slot is partly constructed)
t+2     acquire lock
                    (*lock is acquired)
t+3     add slot to list
t+3     release lock
                    (*slot is added to list)
                    (*lock is released)
t+4     idle                                      [*accesses slot]
t+5                 (*construction of slot is finished)


Is this a possible scenario? I can't think properly about it at the  
moment - too tired. Note that slot is copied again while adding to the  
list during std::list::push_back(). I would assume that this copy is  
fully initialized before the lock is actually released. Of course in  
the case of our std::string this is still a problem because the newly  
constructed string is a shallow copy of the old one. But for static  
data types everything should be all right, shouldn't it?

Regards,

  Martin

[Libsigcx-main] Re: [sigc] Re: [gtkmm] libsigcx and gtkmm 2.4

[Martin S. <mar...@hi...>]

Am 14.06.2004 01:18:56 schrieb(en) Daniel Elstner:
> Am So, den 13.06.2004 um 23:47 Uhr +0200 schrieb Christer Palm:
> 
> > 1. An string object is created.
> > 2. The shared mutex is locked.
> > 3. A shared copy of the string object is made.
> > 4. The mutex is unlocked.
> > 5. The original string object is destroyed.
> >
> > Now, the problem I see here is that the original string is  
> destroyed
> 
> > after the mutex is unlocked. So if string isn't thread-safe this is
> a
> > problem.
> 
> That's indeed another problem.

Hm... after reading:

  http://gcc.gnu.org/onlinedocs/libstdc++/faq/#5_6

I still cannot answer the question whether string (in the example from  
above) _is_ thread-safe?!

Regards,

  Martin


> > But if fail to see how locking the mutex before creating the
> original
> > string would make any difference. Successfully locking or unlocking
> a
> > mutex is guaranteed to synchronize memory with respect to other
> threads
> > regardless of whether that memory was touched before or after the
> mutex
> > was locked.
> 
> That's new to me.  Do you have any reference on that?
> 
> --Daniel
> 
> 
> _______________________________________________
> gtkmm-list mailing list
> gtk...@gn...
> http://mail.gnome.org/mailman/listinfo/gtkmm-list
> 

[Libsigcx-main] Re: [sigc] Re: [gtkmm] libsigcx and gtkmm 2.4

[Martin S. <mar...@hi...>]

Am 14.06.2004 01:20:26 schrieb(en) Daniel Elstner:
> Am So, den 13.06.2004 um 22:18 Uhr +0200 schrieb Martin Schulze:
> 
> > time    thread A should do (*does)               thread B [*does]
> > -------------------------------------------------------------------
> > t       construct slot
> >                     (*slot is partly constructed)
> > t+2     acquire lock
> >                     (*lock is acquired)
> > t+3     add slot to list
> > t+3     release lock
> >                     (*slot is added to list)
> >                     (*lock is released)
> > t+4     idle                                      [*accesses slot]
> > t+5                 (*construction of slot is finished)
> >
> >
> > Is this a possible scenario? I can't think properly about it at the
> 
> > moment - too tired. Note that slot is copied again while adding to
> the
> > list during std::list::push_back(). I would assume that this copy  
> is
> 
> > fully initialized before the lock is actually released. Of course  
> in
> 
> > the case of our std::string this is still a problem because the
> newly
> > constructed string is a shallow copy of the old one. But for static
> 
> > data types everything should be all right, shouldn't it?
> 
> Yes.  But at least in libsigc++ 1.2, slots were reference-counted.
> Has
> this changed in 2.0?

Yes, this has changed. Reference-counting of slots made signal emission  
very complex and had very little benefits. Apart from the template  
clutter which make it hard to read, the internals of libsigc++ 2.0 are  
much more simple than in libsigc++ 1.2!

Cheers,

  Martin