Blog Archives

Help wanted in ModemManager/NetworkManager development!

If you have free time, and experience with gtk-doc documentation or man pages, ModemManager developers will thank you [1] if you help writing the new libmm-common, libmm-glib and mmcli documentation:
[MM 0.6] Documentation

If you have free time, basic GLib/GIO development knowledge, and a broadband modem (either USB dongle or internal) to play with, ModemManager developers will thank you [2] if you port any of the missing plugins to the new codebase in the 06-api branch:
[MM 0.6] Plugins

If you have free time, NetworkManager installed [3] and basic GLib/GIO development knowledge, ModemManager developers will thank you [4] if you help providing support for the new ModemManager1 interface in NetworkManager:
[MM 0.6] NM integration

[1] You’ll get one beer for free if we ever meet.
[2] You’ll get two beers for free if we ever meet.
[3] This already leaves out Jose, Luca and Alfred.
[4] You’ll get three! beers for free if we ever meet.

Knight’s Tour brute force algorithm example

(From Wikipedia) The Knight’s Tour is a mathematical problem involving a knight on a chessboard. The knight is placed on the empty board and, moving according to the rules of chess, must visit each square exactly once. A knight’s tour is called a closed tour if the knight ends on a square attacking the square from which it began (so that it may tour the board again immediately with the same path). Otherwise the tour is open.

Just developed my brute-force algorithm implementation, using GLib and based on a simple recursive function.

Download and try it here!

As an example of result, this is the open Knight’s Tour found by the algorithm in a 5×5 board, starting from position [0,0]:
[0,0][1,2][2,4][4,3][3,1][1,0][2,2][0,3][1,1][3,0][4,2][3,4][1,3][0,1][2,0][4,1][3,3][1,4][0,2][2,1][4,0][3,2][4,4][2,3][0,4]

And this one, the first Knight’s Tour found by the algorithm in a 8×8 board, starting from position [0,0]:
[0,0][1,2][2,4][3,6][5,7][7,6][6,4][7,2][6,0][4,1][5,3][6,5][7,7][5,6][7,5][6,3][7,1][5,0][6,2][7,4][5,5][6,7][4,6][5,4][6,6][4,5][3,3][5,2][7,3][6,1][4,0][2,1][4,2][3,0][1,1][0,3][2,2][0,1][2,0][3,2][4,4][2,3][0,4][1,6][3,7][2,5][1,7][0,5][1,3][3,4][1,5][0,7][2,6][4,7][3,5][2,7][0,6][1,4][0,2][1,0][3,1][4,3][5,1][7,0]

Both examples above show open Knight’s Tours.

g_source_unref() and g_source_destroy() are your friends

After almost 2 years developing GLib-based applications, I understood the proper way of using GSource objects. Yes, quite a shame, but better now than never.

Now, after re-reading carefully the GLib Reference Manual, I see that it is quite clearly explained the difference between g_source_destroy() and g_source_unref(). So the typical suggestion is still the best one: RTFM!!

In our applications, we usually need to attach timeout operations to the context of an specific thread, not to the main thread context. Thus, we cannot use g_timeout_add() or the pretty new g_timeout_add_seconds().

For example, you could create a GThreadPool, and in the function to be executed in each thread, you could create a specific context for the thread, plus a main loop in the context:

    /* Create a GLib Main Context */
    context = g_main_context_new();

    /* Create a Main Loop in the context*/
    main_loop = g_main_loop_new(context,
                                FALSE);

Once you have a new context and main loop, you can just create a new GSource, and attach it to the main loop. As soon as you create the GSource, its reference count is 1, and as soon as you attach it to the main loop, its reference count will be 2.

    /* Create new timeout source to be called
     * every 5 seconds.
     * Reference count of source is 1 once created */
    source = g_timeout_source_new(TIMEOUT_MSECS);

    /* Set callback to be called in each timeout */
    g_source_set_callback(source,
                          (GSourceFunc)__timeout_func,
                          main_loop,
                          NULL);

    /* Attach the GSource in the GMainContext.
     * Reference count of source is 2 after this call */
    g_source_attach(source,
                    context);

Of, course, you will be now running the main loop:

    /* Run the main loop, until it is stopped */
    g_main_loop_run(main_loop);

The key now is how to destroy the GSource properly. When calling g_source_destroy(), you are doing 2 things: first, telling the main loop to forget about the GSource; and second, decrementing the reference count of the GSource. Then, you still need to call g_source_unref() to fully decrement the reference counter so that the GSource is disposed.

    /* We did an attach() with the GSource, so we need to
     * destroy() it */
    g_source_destroy(source);

    /* We need to unref() the GSource to end the last reference
     * we got */
    g_source_unref(source);

To end the example, once the main loop is stopped, you will also need to properly dispose the GMainContext and GMainLoop objects:

    /* The main loop should be destroyed before the context */
    g_main_loop_unref(main_loop);

    /* Finally, destroy the context */
    g_main_context_unref(context);

This is just one way of keeping the GSource references properly managed:

  1. You get one reference when you create the GSource
  2. You get a new reference when you attach it in the context
  3. You release one reference when you destroy it from the context
  4. You release last reference when you unref the final one

Of course, you could also choose to avoid storing the “extra” reference, and leave alive only the one inside the main context:

  1. You get one reference when you create the GSource
  2. You get a new reference when you attach it in the context
  3. You release one reference when you unref the the GSource —> Now, the only reference is inside the GMainContext
  4. You release last reference when you destroy it from the context

You can check this simple example in the following program I prepared, released into public domain:
http://es.gnu.org/~aleksander/glib/test-gsource.c

Hope it helps someone out there to fully understand the difference between g_source_destroy() and g_source_unref().

As last comment… I would really rename the following functions in the library, so that no one else is confused with the “unref” and “destroy” terms:

  • Rename g_source_attach() to g_source_attach_to_context()
  • Rename g_source_destroy() to g_source_destroy_from_context()

The main reason is that these two operations actually act on the GMainContext, while the name of the functions do not suggest that fact.

Follow

Get every new post delivered to your Inbox.

Join 36 other followers