Ticket #43346: patch-glib-gmain-c.diff

File patch-glib-gmain-c.diff, 2.3 KB (added by ccorn@…, 11 years ago)

Patch to get g_get_monotonic_time working on MACH/PPC

  • glib/gmain.c

    old new g_get_monotonic_time (void) 
    26472647gint64
    26482648g_get_monotonic_time (void)
    26492649{
    2650   static mach_timebase_info_data_t timebase_info;
     2650  static long double mach_tick_period_usec;
    26512651
    2652   if (timebase_info.denom == 0)
     2652  if (mach_tick_period_usec == 0.0L)
    26532653    {
     2654      mach_timebase_info_data_t timebase_info;
     2655      mach_timebase_info (&timebase_info);
    26542656      /* This is a fraction that we must use to scale
    26552657       * mach_absolute_time() by in order to reach nanoseconds.
    2656        *
    2657        * We've only ever observed this to be 1/1, but maybe it could be
    2658        * 1000/1 if mach time is microseconds already, or 1/1000 if
    2659        * picoseconds.  Try to deal nicely with that.
     2658       * Example value: 1000000000/33330748
    26602659       */
    2661       mach_timebase_info (&timebase_info);
    2662 
    2663       /* We actually want microseconds... */
    2664       if (timebase_info.numer % 1000 == 0)
    2665         timebase_info.numer /= 1000;
    2666       else
    2667         timebase_info.denom *= 1000;
    2668 
    2669       /* We want to make the numer 1 to avoid having to multiply... */
    2670       if (timebase_info.denom % timebase_info.numer == 0)
    2671         {
    2672           timebase_info.denom /= timebase_info.numer;
    2673           timebase_info.numer = 1;
    2674         }
    2675       else
    2676         {
    2677           /* We could just multiply by timebase_info.numer below, but why
    2678            * bother for a case that may never actually exist...
    2679            *
    2680            * Plus -- performing the multiplication would risk integer
    2681            * overflow.  If we ever actually end up in this situation, we
    2682            * should more carefully evaluate the correct course of action.
    2683            */
    2684           mach_timebase_info (&timebase_info); /* Get a fresh copy for a better message */
    2685           g_error ("Got weird mach timebase info of %d/%d.  Please file a bug against GLib.",
    2686                    timebase_info.numer, timebase_info.denom);
    2687         }
     2660      mach_tick_period_usec = timebase_info.numer/(1000.0L*timebase_info.denom);
    26882661    }
    2689 
    2690   return mach_absolute_time () / timebase_info.denom;
     2662  /* Assuming long double has at least 64 mantissa bits,
     2663   * this computation is as accurate as it can be.
     2664   * Result is truncated towards zero.
     2665   */
     2666  return (gint64)(mach_absolute_time () * mach_tick_period_usec);
    26912667}
    26922668#else
    26932669gint64