Thursday, 8 December 2016

Re: cups-browsed uses GMainLoop and global variables, how to introduce locks against race conditions?

On Wed, 2016-12-07 at 17:39 -0200, Till Kamppeter wrote:
On 12/02/2016 04:13 PM, Till Kamppeter wrote:  
The way how cups-browsed works is the following: First, a GMainLoop is created: gmainloop = g_main_loop_new (NULL, FALSE); Browsing for legacy CUPS broadcasts is attached to the mail loop via GIOChannel *browse_channel = g_io_channel_unix_new (browsesocket); g_io_channel_set_close_on_unref (browse_channel, FALSE); g_io_add_watch (browse_channel, G_IO_IN, process_browse_data, NULL); Many other things are added via g_idle_add () and g_timeout_add_seconds () Reaction to D-Bus notifications is added via the g_signal_connect() function. Avahi browsing is set up with these calls /* Allocate main loop object */ if (!glib_poll) if (!(glib_poll = avahi_glib_poll_new(NULL, G_PRIORITY_DEFAULT))) { debug_printf("ERROR: Failed to create glib poll object.\n"); goto avahi_init_fail; } /* Allocate a new client */ if (!client) client = avahi_client_new(avahi_glib_poll_get(glib_poll), AVAHI_CLIENT_NO_FAIL, client_callback, NULL, &error); /* Check wether creating the client object succeeded */ if (!client) { debug_printf("ERROR: Failed to create client: %s\n", avahi_strerror(error)); goto avahi_init_fail; } Strange is that this Avahi browsing setup is done before creation of the main loop. Also some g_timeout_add_seconds () calls are done before creating the main loop. After that, the main loop gets started via g_main_loop_run (gmainloop); My questions are now: - Is this way everything attached to the main loop? - Do I have to do function calls in the beginning and in the end of each callback function to acquire and release a lock? Which ones? - If something of this is not attached to the main loop, how do I attach it? I do not explicitly start any new threads. Till
No one has any idea to help me here?

If there are no threads, then there isn't any locking needed on the data structure, so it's probably something else that is causing your problem. But you're probably out of mailing list territory at this point, need a way to recreate and to find someone who has time to look through the code.

Ted

Looking for list moderators

Hello everybody,

I'm looking for additional moderators for some of our mailing lists.

It's not a lot of work, it's just a matter of setting up the listadmin
tool and running it regularly. In a lot of cases our spam filters let
some mails through, in other cases there are genuine mails which need
moderation. Sometimes there's an off-topic post or other issues to deal
with, but not so often.

It's the following lists:

[email protected]
[email protected]
[email protected]
[email protected]
[email protected]


If you are an Ubuntu member and a trusted contributor to those lists,
I'm happy to share access and let you know the process. Just drop me a
private email letting me know which list(s) you want to look after.

Thanks a lot in advance.

Have a great day,
Daniel

--
Get started with Snapcraft! Check https://snapcraft.io
Follow @snapcraftio on twitter.com/facebook.com/G+


--
ubuntu-devel mailing list
[email protected]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Wednesday, 7 December 2016

Ubuntu Kernel Team - Weekly Newsletter, 2016-12-06

Hello,

The Ubuntu Kernel Team has published this weeks newsletter[0].

The Newsletter is published weekly. It contains highlights from the
week, announcements regarding the development and stable kernels, as
well as any other news the Kernel Team may have.

Sincerely,

The Ubuntu Kernel Team


[0] https://wiki.ubuntu.com/KernelTeam/Newsletter/2016-12-06


--
ubuntu-devel mailing list
[email protected]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: cups-browsed uses GMainLoop and global variables, how to introduce locks against race conditions?

On 12/02/2016 04:13 PM, Till Kamppeter wrote:
> The way how cups-browsed works is the following:
>
> First, a GMainLoop is created:
>
> gmainloop = g_main_loop_new (NULL, FALSE);
>
> Browsing for legacy CUPS broadcasts is attached to the mail loop via
>
> GIOChannel *browse_channel = g_io_channel_unix_new (browsesocket);
> g_io_channel_set_close_on_unref (browse_channel, FALSE);
> g_io_add_watch (browse_channel, G_IO_IN, process_browse_data, NULL);
>
> Many other things are added via
>
> g_idle_add ()
>
> and
>
> g_timeout_add_seconds ()
>
> Reaction to D-Bus notifications is added via the
>
> g_signal_connect()
>
> function.
>
> Avahi browsing is set up with these calls
>
> /* Allocate main loop object */
> if (!glib_poll)
> if (!(glib_poll = avahi_glib_poll_new(NULL, G_PRIORITY_DEFAULT)))
> {
> debug_printf("ERROR: Failed to create glib poll object.\n");
> goto avahi_init_fail;
> }
>
> /* Allocate a new client */
> if (!client)
> client = avahi_client_new(avahi_glib_poll_get(glib_poll),
> AVAHI_CLIENT_NO_FAIL,
> client_callback, NULL, &error);
>
> /* Check wether creating the client object succeeded */
> if (!client) {
> debug_printf("ERROR: Failed to create client: %s\n",
> avahi_strerror(error));
> goto avahi_init_fail;
> }
>
> Strange is that this Avahi browsing setup is done before creation of the
> main loop. Also some g_timeout_add_seconds () calls are done before
> creating the main loop.
>
> After that, the main loop gets started via
>
> g_main_loop_run (gmainloop);
>
> My questions are now:
>
> - Is this way everything attached to the main loop?
>
> - Do I have to do function calls in the beginning and in the end of each
> callback function to acquire and release a lock? Which ones?
>
> - If something of this is not attached to the main loop, how do I attach
> it?
>
> I do not explicitly start any new threads.
>
> Till
>

No one has any idea to help me here?

Till


--
ubuntu-devel mailing list
[email protected]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Dropping LXC backend from Ubuntu's libvirtd

On Wed, Dec 7, 2016 at 3:49 AM, Stéphane Graber <[email protected]> wrote:
> Hey there,
>
> Ubuntu's libvirt currently ships with its own Linux Containers
> implementation (confusingly called libvirt-lxc).
>
> This code has nothing to do with upstream LXC, confuses users who expect
> that it does and is in general a much worse experience that the one we
> provide through LXD in Ubuntu.
>
> We'd rather not have to maintain that feature in main and given that
> libvirt backends can't be split into separate packages (at least
> trivially), we're now looking at turning libvirt-lxc altogether.
>
> Red Hat, who was the main driver for this particular driver has also dropped
> support for it back in March 2015[1] (in favor of Docker support).
>
>
> If you are a current user of libvirt-lxc, we'd be very interested to
> hear from you about your use case for it, especially about anything
> which libvirt-lxc is providing which you can't achieve with LXC/LXD.
>
> Thanks!
>
> [1] https://access.redhat.com/articles/1365153
>

This is news to me, because in Fedora, we *do* ship the libvirt-lxc
driver as a separate subpackage[1], and we have for a very long time.
Also, libvirt definitely did not drop support for LXC, and it's still
offered in Fedora.

Red Hat has decided to drop it from Red Hat Enterprise Linux, but that
doesn't mean that it's not still available and maintained.

[1]: http://koji.fedoraproject.org/koji/buildinfo?buildID=822727


--
真実はいつも一つ!/ Always, there's only one truth!

--
ubuntu-devel mailing list
[email protected]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Re: Dropping LXC backend from Ubuntu's libvirtd

On Wed, Dec 07, 2016 at 09:49:23AM +0100, Stéphane Graber wrote:
> Hey there,
>
> Ubuntu's libvirt currently ships with its own Linux Containers
> implementation (confusingly called libvirt-lxc).
>
> This code has nothing to do with upstream LXC, confuses users who expect
> that it does and is in general a much worse experience that the one we
> provide through LXD in Ubuntu.
>
> We'd rather not have to maintain that feature in main and given that
> libvirt backends can't be split into separate packages (at least
> trivially), we're now looking at turning libvirt-lxc altogether.
>
> Red Hat, who was the main driver for this particular driver has also dropped
> support for it back in March 2015[1] (in favor of Docker support).

In the interest of fairness, note that while rh dropped support, *libvirt*
did not.

Please make sure to seek input from the openstack types, as they would
probably be the most likely to be using libvirt-lxc.

> If you are a current user of libvirt-lxc, we'd be very interested to
> hear from you about your use case for it, especially about anything
> which libvirt-lxc is providing which you can't achieve with LXC/LXD.
>
> Thanks!
>
> [1] https://access.redhat.com/articles/1365153
>
> --
> Stéphane Graber
> Ubuntu developer
> http://www.ubuntu.com



> --
> ubuntu-devel mailing list
> [email protected]
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel


--
ubuntu-devel mailing list
[email protected]
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Dropping LXC backend from Ubuntu's libvirtd

Hey there,

Ubuntu's libvirt currently ships with its own Linux Containers
implementation (confusingly called libvirt-lxc).

This code has nothing to do with upstream LXC, confuses users who expect
that it does and is in general a much worse experience that the one we
provide through LXD in Ubuntu.

We'd rather not have to maintain that feature in main and given that
libvirt backends can't be split into separate packages (at least
trivially), we're now looking at turning libvirt-lxc altogether.

Red Hat, who was the main driver for this particular driver has also dropped
support for it back in March 2015[1] (in favor of Docker support).


If you are a current user of libvirt-lxc, we'd be very interested to
hear from you about your use case for it, especially about anything
which libvirt-lxc is providing which you can't achieve with LXC/LXD.

Thanks!

[1] https://access.redhat.com/articles/1365153

--
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com