Send Gtkmm-forge mailing list submissions to
        [EMAIL PROTECTED]

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.sourceforge.net/lists/listinfo/gtkmm-forge
or, via email, send a message with subject or body 'help' to
        [EMAIL PROTECTED]

You can reach the person managing the list at
        [EMAIL PROTECTED]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Gtkmm-forge digest..."


gtkmm-forge is the mailing list that receives gtkmm bug reports from bugzilla.  
A daily digest is sent to gtkmm-main, to encourage people to help fixing the 
bugs. Do not try to unsubscribe gtkmm-forge from gtkmm-list.


Today's Topics:

   1. [Bug 511972] glibmm doesn't have an AsyncQueue    class
      (glibmm (bugzilla.gnome.org))
   2. [Bug 511972] glibmm doesn't have an AsyncQueue    class
      (glibmm (bugzilla.gnome.org))
   3. [Bug 511708] svn build failed: No conversion from const
      gchar* to const Glib::ustring& (glibmm (bugzilla.gnome.org))
   4. [Bug 511972] glibmm doesn't have an AsyncQueue    class
      (glibmm (bugzilla.gnome.org))
   5. [Bug 511972] glibmm doesn't have an AsyncQueue    class
      (glibmm (bugzilla.gnome.org))
   6. [Bug 512348] New: Glib::Thread::create() does not appear to
      be thread safe (glibmm (bugzilla.gnome.org))
   7. [Bug 512348] Glib::Thread::create() does not      appear to be
      thread safe (glibmm (bugzilla.gnome.org))


----------------------------------------------------------------------

Message: 1
Date: Sat, 26 Jan 2008 11:07:46 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
        <[EMAIL PROTECTED]>
Subject: [gtkmm bugzilla] [Bug 511972] glibmm doesn't have an
        AsyncQueue      class
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=utf-8

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=511972

  glibmm | threads | Ver: 2.15.x

Murray Cumming changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[EMAIL PROTECTED]




------- Comment #3 from Murray Cumming  2008-01-26 11:07 UTC -------
Could you start a discussion about this on gtkmm-list, please. I'd like more
opinions.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why 
you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at 
http://bugzilla.gnome.org/show_bug.cgi?id=511972.



------------------------------

Message: 2
Date: Sat, 26 Jan 2008 11:08:55 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
        <[EMAIL PROTECTED]>
Subject: [gtkmm bugzilla] [Bug 511972] glibmm doesn't have an
        AsyncQueue      class
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=utf-8

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=511972

  glibmm | threads | Ver: 2.15.x




------- Comment #4 from Murray Cumming  2008-01-26 11:08 UTC -------
And of course it would be helpful if the documentation was in English (rather
than French) and if it was formatted like the rest of glibmm.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why 
you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at 
http://bugzilla.gnome.org/show_bug.cgi?id=511972.



------------------------------

Message: 3
Date: Sat, 26 Jan 2008 12:46:40 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
        <[EMAIL PROTECTED]>
Subject: [gtkmm bugzilla] [Bug 511708] svn build failed: No conversion
        from    const gchar* to const Glib::ustring&
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=utf-8

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=511708

  glibmm | general | Ver: 2.4.x

Murray Cumming changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED




------- Comment #9 from Murray Cumming  2008-01-26 12:46 UTC -------
I now experienced the problem and fixed it in gtkmm and in cluttermm.

2008-01-26  Murray Cumming  <[EMAIL PROTECTED]>

        * atk/src/action.hg:
        * atk/src/editabletext.hg:
        * atk/src/image.hg:
        * atk/src/object.hg:
        * atk/src/streamablecontent.hg:
        * gtk/src/celllayout.hg:
        * gtk/src/cellrenderer.hg:
        * gtk/src/cellrendereraccel.hg:
        * gtk/src/cellrenderertext.hg:
        * gtk/src/cellrenderertoggle.hg:
        * gtk/src/entry.hg:
        * gtk/src/entrycompletion.hg:
        * gtk/src/recentchooser.hg:
        * gtk/src/statusbar.hg:
        * gtk/src/style.hg:
        * gtk/src/textview.hg: Added conversions from const gchar* to const
ustring&, 
        to fix the build I guess I removed this from a convert_*.m4 file, to
discourage  
        people from returning const ustring& from methods.
        Bug #511708 (Jos? Alburquerque).

Thanks.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why 
you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at 
http://bugzilla.gnome.org/show_bug.cgi?id=511708.



------------------------------

Message: 4
Date: Sun, 27 Jan 2008 01:04:36 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
        <[EMAIL PROTECTED]>
Subject: [gtkmm bugzilla] [Bug 511972] glibmm doesn't have an
        AsyncQueue      class
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=utf-8

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=511972

  glibmm | threads | Ver: 2.15.x

[EMAIL PROTECTED] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[EMAIL PROTECTED]




------- Comment #5 from [EMAIL PROTECTED]  2008-01-27 01:04 UTC -------
"Could you start a discussion about this on gtkmm-list, please. I'd like more
opinions."

In the absence of that, basing a thread safe queue on GAsyncQueue itself in
glibmm would not in my view be sensible.  We have std::queue and applying
thread safe wrappers to one is relatively straightforward, and the
implementation that has been offered for this is quite reasonable, except that
it loses strong exception safety in the pop() method as it copies to the return
value after popping the value at the front of the queue (there is some
discussion about this in one of the Herb Sutter's books).

The normal solution to this in locked queues where everything has to be done
under a single atomic lock is for the pop() method to take a reference argument
and pass the value at the front of the queue by reference rather than as a
return value, which avoids a copy.


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why 
you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at 
http://bugzilla.gnome.org/show_bug.cgi?id=511972.



------------------------------

Message: 5
Date: Sun, 27 Jan 2008 05:46:17 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
        <[EMAIL PROTECTED]>
Subject: [gtkmm bugzilla] [Bug 511972] glibmm doesn't have an
        AsyncQueue      class
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=utf-8

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=511972

  glibmm | threads | Ver: 2.15.x




------- Comment #6 from Murray Cumming  2008-01-27 05:46 UTC -------
So we would have to make the usual decision about whether glibmm is the right
place to put this, considering that glibmm is meant for wrappers of glib. We
have broken this rule already for Glib::Dispatcher and ustring::compose()
though. Does this feel as useful?


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why 
you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at 
http://bugzilla.gnome.org/show_bug.cgi?id=511972.



------------------------------

Message: 6
Date: Sun, 27 Jan 2008 11:08:38 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
        <[EMAIL PROTECTED]>
Subject: [gtkmm bugzilla] [Bug 512348] New: Glib::Thread::create()
        does not        appear to be thread safe
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]/>
Content-Type: text/plain; charset=utf-8

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=512348

  glibmm | threads | Ver: 2.14.x
           Summary: Glib::Thread::create() does not appear to be thread safe
           Product: glibmm
           Version: 2.14.x
          Platform: Other
        OS/Version: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: threads
        AssignedTo: [EMAIL PROTECTED]
        ReportedBy: [EMAIL PROTECTED]
         QAContact: [EMAIL PROTECTED]
     GNOME version: 2.19/2.20
   GNOME milestone: Unspecified


Please describe the problem:
Glib::Thread::create() constructs a new slot and passes it by pointer to the
new thread through the thread function call_thread_entry_slot().  Where the
method bound to the slot belongs to a class object derived from
sigc::trackable, its creation appears to manipulate a list of notification
callbacks (a std::list<> object) maintained by the sigc::trackable object.  The
same slot is disposed of in the new thread (a different thread), which also
invokes the same list.

That is not of itself problematic since clearly the deregistration of
the slot in call_thread_entry_slot() cannot occur concurrently with its
registration.  However, it could occur at the same time that the
original thread is creating new slots for the same target object whose
method was bound to the slot: in that case, there would be undefined
behaviour.

See http://mail.gnome.org/archives/gtkmm-list/2008-January/msg00261.html for a
more detailed explanation.

Steps to reproduce:
1. 
2. 
3. 


Actual results:


Expected results:


Does this happen every time?


Other information:
It is difficult to see a way around this with the current libsigc++
implementation - it would probably require a new argument on slot creation
allowing sigc::trackable to be ignored.

In the meantime I have knocked up an implementation of a callback class which
avoids this and which I will post and is trivial to use (but it is probably not
the way glibmm will want to go).  It also disposes of bug 396958


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why 
you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at 
http://bugzilla.gnome.org/show_bug.cgi?id=512348.



------------------------------

Message: 7
Date: Sun, 27 Jan 2008 11:09:39 +0000 (UTC)
From: "glibmm (bugzilla.gnome.org)"
        <[EMAIL PROTECTED]>
Subject: [gtkmm bugzilla] [Bug 512348] Glib::Thread::create() does not
        appear to be thread safe
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=utf-8

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=512348

  glibmm | threads | Ver: 2.14.x




------- Comment #1 from [EMAIL PROTECTED]  2008-01-27 11:09 UTC -------
Created an attachment (id=103813)
 --> (http://bugzilla.gnome.org/attachment.cgi?id=103813&action=view)
Example of one solution


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why 
you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at 
http://bugzilla.gnome.org/show_bug.cgi?id=512348.



------------------------------

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

------------------------------

_______________________________________________
Gtkmm-forge mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/gtkmm-forge


End of Gtkmm-forge Digest, Vol 20, Issue 10
*******************************************
_______________________________________________
gtkmm-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gtkmm-list

Reply via email to