Skip site navigation (1) Skip section navigation (2)

Re: [PATCHES] Avahi support for Postgresql

From: Mathias Hasselmann <mathias(at)openismus(dot)com>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org,Murray Cumming <murrayc(at)openismus(dot)com>
Subject: Re: [PATCHES] Avahi support for Postgresql
Date: 2008-02-25 19:40:50
Message-ID: 1203968450.7227.60.camel@localhost (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Am Montag, den 25.02.2008, 14:32 -0300 schrieb Alvaro Herrera:
> Peter Eisentraut wrote:
> > Am Montag, 25. Februar 2008 schrieb Alvaro Herrera:
> > > Hmm, a quick look at the third patch reveals that it is using the
> > > "threaded" Avahi client.  That's a showstopper.
> > 
> > Could you elaborate why that is?
> Because it creates a new thread under the Postmaster to handle Avahi
> events, if I'm reading the Avahi docs right.  This is verboten.

Just to be sure we talk about the same topic: I assume the prohibition
you talk about is something like "no use of threads in Postmaster"?

If that's the case: Are there some docs, mails, ... explaining the
rationale behind this restriction? I could imagine your do not want
random locking in the postmaster code?

See, interaction points with the main thread are very small:

1) Lock-free creation of the threaded Avahi client in PostmasterMain()
2) Locked shutdown of the Avahi client in ExitAvahiClient(), which only
   is called from ExitPostmaster().

So IMHO usage of the threaded poll API has much smaller impact on the
behavior of the postmaster process, than any attempt to integrate Avahi
with postmaster's main loop.

> We have an event loop in the postmaster -- see ServerLoop.  Is there a
> reason the Avahi events could not be hooked in there?

Currently there are four ___well tested___ implementations of Avahi's
poll API: AvahiSimplePoll, which really just works for simple command
line tools and demonstration purposes. The single threaded APIs that
integrate with the main loops of glib and Qt, and the threaded poll API.

Avahi's requirements for a poll API aren't exactly trivial: You don't
only have to care about file descriptors, you also have to implement
some kind of timeout scheduling. So in favor of reinventing the wheel
and delivering an untested custom poll API, I've chosen the threaded
poll API: It's the only well-tested poll API that fits into Postgresql,
and its interaction points with the Postmaster process are minimal.

>From looking at ServerLoop() I do not see any facilities for
registering timeout callbacks. Select timeouts are static. So for
implementing Avahi's poll API in ServerLoop() some radical code changes
would be needed. I don't believe such changes would be justified,
unless other portions of postmaster also need timeout callbacks.

Mathias Hasselmann <mathias(at)openismus(dot)com> - We can get it done.

In response to


pgsql-hackers by date

Next:From: Christopher BrowneDate: 2008-02-25 19:58:18
Subject: Re: Tuning 8.3
Previous:From: Jeff DavisDate: 2008-02-25 19:36:56
Subject: Re: 8.3 / 8.2.6 restore comparison

pgsql-patches by date

Next:From: Tom LaneDate: 2008-02-25 20:08:29
Subject: Re: [PATCHES] Avahi support for Postgresql
Previous:From: Tom LaneDate: 2008-02-25 19:35:02
Subject: Re: [PATCHES] Avahi support for Postgresql

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group