Pango 1.11.1 released
Behdad stayed up all night to finish Pango 1.11.1 before leaving for the holidays. Thanks, Behdad ! Pango 1.11.1 is now available for download at: ftp://ftp.gtk.org/pub/gtk/v2.9 http://ftp.gnome.org/pub/GNOME/sources/pango/1.11 pango-1.11.1.tar.bz2 c6255bba9bb738a564716fd57b7cc546 pango-1.11.1.tar.gz af6d609510fe5c0d35a3f8f863135b7c This is the second development release leading up to 1.12. Overview of changes between 1.11.0 and 1.11.1 = * ATSUI support for the cairo backend. [Anders Carlsson] * Fixed a couple of regressions with font size and scaling. * Draw a dashed empty box on missing glyphs for cairo-fc backend. * Support OpenType features for basic (Latin/Greek/...) module. * Support swash feature in Arabic module. * Misc bug fixes. * Misc documentation improvements. Optimizations: * Cache GObject private data in PangoFcFont.priv [Federico Mena Quintero] * Add a constant-sized light-weight cache for glyph extents. * Use g_slice_* instead of GMemChunk in mini-fribidi. December 12, 2005 Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: public barrier functions
On Mon, Dec 12, 2005 at 10:41:55PM +0100, Sebastian Wilhelmi wrote: > > And while I am at it, would it be possible to change the atomic > > operations to inline functions? I'd think it is much better inline > > single-instruction functions as otherwise the call overhead is too > > great. > > That would make it impossible to fix the corresponding implementations > also for already compiled programs, should bugs surface (which they > already did) and it would also make it impossible to guarantee, that all > programs really use the same implementation, i.e. with inline functions > one module could use the asm version (because gcc is used) and the > second module would use the mutex versions (because another compiler is > used). That would be very bad of course. Yes, I'd agree here. I think it's more important to have a consistent library of such operations across all programs, an an easy way to apply bugfixes, than it is to have down-to-the-cycle optimisation. But I'd be interested to see some benchmarks; see how much this actually matters. Run a typical program twice; once with functions and once with some inlines/macros. It's quite likely that in a real-world program, the ratio of time it actually spends doing the atomic operation function calls, to the amount of CPU time in general, will actually be rather small indeed. Such an optimisation is likely to be of little actual benefit, for the cost it brings. -- Paul "LeoNerd" Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: Digital signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: public barrier functions
Hi Balazs,
> Is there a specific reasons why the barrier functions implemented by
> gatomic.c and gatomic.h are not exported APIs?
We didn't want to create the Swiss army knife for high performance
multithread programming, just atomic integers. As you are surely aware,
using memory barriers is far from an easy topic and bugs are easily
introduced.
> I'd like to avoid locking in some situations where these memory barrier
> instructions would come handy.
>
> One thread:
> ptr = NULL
>
> Other thread:
> void *my_ptr = ptr;
>
> if (ptr)
> {
> }
>
> Of course this would be a race condition if I was trying to use the
> pointer, but if I add reference counting like this:
>
> One thread:
> loc_ptr = ptr;
> ptr = NULL;
> g_data_unref(loc_ptr);
>
> Other thread:
> void *my_ptr = g_data_ref(ptr);
>
> if (my_ptr)
> {
> }
>
> Unless I miss something this should work, provided:
> 1) provided g_data_ref handles NULL pointers
> 2) the reference count of ptr itself is manipilated with atomic
> operations.
> 3) the CPU ensures proper read/write memory ordering
>
> Now this is not true on some non-x86 CPUs in which case I'd need
> something like:
>
> One thread:
> loc_ptr = ptr;
> ptr = NULL;
> wmb();
> g_data_unref(loc_ptr);
>
> Other thread:
> void *my_ptr = g_data_ref(ptr);
>
> if (my_ptr)
> {
> }
>
> Now the question is why the memory barrier macros are hidden in the
> gatomic module and not exported.
Actually I'm not quite sure, what you want to achieve here. Can you
elaborate? However for transferring pointers from one thread to another
you can use g_atomic_pointer_compare_and_exchange for writing and
g_atomic_pointer_get for reading and be ready.
> And while I am at it, would it be possible to change the atomic
> operations to inline functions? I'd think it is much better inline
> single-instruction functions as otherwise the call overhead is too
> great.
That would make it impossible to fix the corresponding implementations
also for already compiled programs, should bugs surface (which they
already did) and it would also make it impossible to guarantee, that all
programs really use the same implementation, i.e. with inline functions
one module could use the asm version (because gcc is used) and the
second module would use the mutex versions (because another compiler is
used). That would be very bad of course.
Bye,
Sebastian
--
Sebastian Wilhelmi |här ovanför alla molnen
mailto:[EMAIL PROTECTED] | är himlen så förunderligt blå
http://seppi.de
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: inlining glib functions (Was: public barrier functions)
On Mon, 2005-12-12 at 18:44 +, Gustavo J. A. M. Carneiro wrote:
> Seg, 2005-12-12 às 19:29 +0100, Balazs Scheidler escreveu:
> [...]
> >
> > And while I am at it, would it be possible to change the atomic
> > operations to inline functions? I'd think it is much better inline
> > single-instruction functions as otherwise the call overhead is too
> > great.
>
> I agree. Also many other glib functions could be static inline in the
> public header files. For instance, many of the functions in glist.c and
> gslist.c are really tiny, thus could easily be inlined, but aren't
> because the compiler has no access to their implementation, only to
> their prototype.
One problem I see with this is binary compatibility. The shared lib
version of glib has to provide the old non-inlined symbols, and simply
moving the functions to the header as "static inline" would remove those
symbols, even though I would not be surprised if this could be worked
around with some gcc trickery, something along the lines of:
gatomic.h:
static inline void
g_atomic_int_inc(gint *value)
{
...
}
ginlineimpls.c (probably auto-generated in some way):
#define g_atomic_int_inc __inline_g_atomic_int_inc
#include
#undef g_atomic_int_inc
void
g_atomic_int_inc(gint *value)
{
__inline_g_atomic_int_inc(value);
}
Other opinions?
--
Bazsi
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: inlining glib functions (Was: public barrier functions)
Seg, 2005-12-12 às 19:29 +0100, Balazs Scheidler escreveu: [...] > > And while I am at it, would it be possible to change the atomic > operations to inline functions? I'd think it is much better inline > single-instruction functions as otherwise the call overhead is too > great. I agree. Also many other glib functions could be static inline in the public header files. For instance, many of the functions in glist.c and gslist.c are really tiny, thus could easily be inlined, but aren't because the compiler has no access to their implementation, only to their prototype. -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. signature.asc Description: Esta é uma parte de mensagem assinada digitalmente ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
public barrier functions
Hi,
Is there a specific reasons why the barrier functions implemented by
gatomic.c and gatomic.h are not exported APIs?
I'd like to avoid locking in some situations where these memory barrier
instructions would come handy.
One thread:
ptr = NULL
Other thread:
void *my_ptr = ptr;
if (ptr)
{
}
Of course this would be a race condition if I was trying to use the
pointer, but if I add reference counting like this:
One thread:
loc_ptr = ptr;
ptr = NULL;
g_data_unref(loc_ptr);
Other thread:
void *my_ptr = g_data_ref(ptr);
if (my_ptr)
{
}
Unless I miss something this should work, provided:
1) provided g_data_ref handles NULL pointers
2) the reference count of ptr itself is manipilated with atomic
operations.
3) the CPU ensures proper read/write memory ordering
Now this is not true on some non-x86 CPUs in which case I'd need
something like:
One thread:
loc_ptr = ptr;
ptr = NULL;
wmb();
g_data_unref(loc_ptr);
Other thread:
void *my_ptr = g_data_ref(ptr);
if (my_ptr)
{
}
Now the question is why the memory barrier macros are hidden in the
gatomic module and not exported.
And while I am at it, would it be possible to change the atomic
operations to inline functions? I'd think it is much better inline
single-instruction functions as otherwise the call overhead is too
great.
Thanks in advance,
--
Bazsi
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Updated proposal for making the GtkFileChooser code asynchronous
On Fri, 9 Dec 2005, Kristian Rietveld wrote:
1. Let's start out with a somewhat more general change. We need to be able
to cancel currently running asynchronous operations. For this we need
to have a handle on an operation, so we need to introduce a
GtkFileSystemHandle. The GtkFileSystemHandle will be a GObject:
struct _GtkFileSystemHandle
{
GObject parent_instance;
GtkFileSystem *file_system;
guint cancelled : 1;/* indicates whether the operation
has been cancelled or not */
};
struct _GtkFileSystemHandleClass
{
GObjectClass parent_class;
};
File system backends can of course subclass GtkFileSystemHandle and
add their own fields as required. We will add a call which we can use to
actually cancel an operation:
void gtk_file_system_cancel_operation (GtkFileSystemHandle *handle);
is ->cancelled to be exported as a GObject property ::cancelled as well,
so one could possibly listen to ::notify::cancelled?
4. gtk_file_system_create_folder() needs to be changed in order to be able
to operate asynchronously. The new prototypes:
typedef void (* GtkFileSystemCreateFolderCallback) (GtkFileSystemHandle
*handle,
const GtkFilePath
*path
GError
*error,
gpointer
data);
GtkFileSystemHandle *gtk_file_system_create_folder (GtkFileSystem
*file_system,
const GtkFilePath
*path,
GtkFileSystemCreateFolderCallback callback,
gpointer
data);
The error reporting works on the same way as the other functions.
does cancellation of gtk_file_system_create_folder() guarantee that no
new folder was created?
- what happens if gtk_file_system_cancel_operation() is called after a
successfull mkdir() but before GtkFileSystemCreateFolderCallback() is called?
- what happens if gtk_file_system_cancel_operation() is called after
GtkFileSystemCreateFolderCallback() was called (or from within)?
thanks,
-kris.
---
ciaoTJ
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Updated proposal for making the GtkFileChooser code asynchronous
On Fri, 9 Dec 2005, Soeren Sandmann wrote: Soeren Sandmann <[EMAIL PROTECTED]> writes: Also, the callback is always called, even if you cancel the operation, right? If it isn't, then - How do you free the user data you passed in? - What good is the handle passed to the callback? You can't do anything with it, except cancelling the operation which by then is already complete. you can access ->file_system from the handle, so the file_system argument could be left out from the argument list of the callbacks in the updated proposal, and you can reference count the handle which is why it was made into a GObject. Soren --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
