JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for MOONSHOT-COMMUNITY Archives


MOONSHOT-COMMUNITY Archives

MOONSHOT-COMMUNITY Archives


MOONSHOT-COMMUNITY@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

MOONSHOT-COMMUNITY Home

MOONSHOT-COMMUNITY Home

MOONSHOT-COMMUNITY  July 2011

MOONSHOT-COMMUNITY July 2011

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

Re: Moonshot common C stub library

From:

Sam Hartman <[log in to unmask]>

Reply-To:

Moonshot community list <[log in to unmask]>, Sam Hartman <[log in to unmask]>

Date:

Mon, 4 Jul 2011 19:32:55 -0400

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (108 lines)

>>>>> "Sam" == Sam Thursfield <[log in to unmask]> writes:

    >> A dependency on glib is fine provided that  it won't be a problem.
    >> 
    >> note that I was expecting a synchronous interface; I was expecting you
    >> to run any event loop you needed while calls were in progress.  Your
    >> code will need to deal with being entered from multiple threads at the
    >> same time; running multiple event loops is a fine solution to this
    >> assuming that each thread ends up with its own socket to dbus and this
    >> works on Windows.

    Sam> That simplifies things for me. I presume your plan is to call
    Sam> get_identity() from a separate thread then so no UI blocking
    Sam> occurs. 

Well, something like the ssh command line app just blocks.
One hopes something like pidgin calls GSS from its own thread.
IN practice, I suspect we'll find some people who forget that GSS is
allowed to block and produce non-ideal experiences.
But that's an app bug and until GSS has an asynchronous API, we don't
have a lot of options.

    Sam> Multiple calls will be fine (although I'm confused why an app
    Sam> would need to request multiple identities simultaneously)

When my pidgin starts up I log into about 5 chat services.
I only have one mail account on my desktop, but I know a lot of people
who have several.

    >> So, I said that glib was fine provided that it didn't introduce
    >> problems. The GSS-API mechanism is loaded into a process indirectly. A
    >> process will not typically know that it is using moonshot and so it will
    >> not link based on things moonshot does. The process may or may not be
    >> threaded; the process may or may not link to a threads library. On some
    >> platforms, such as Linux, linking to a threads library in a plugin has
    >> some interesting effects, for example mutexes initialized before the
    >> threads library is linked may not be used after the threads library
    >> joins the process.
    >> 
    >> I don't remember if we pull in the pthreads library; we use thread
    >> specific data and mutexes, but I don't think we actually use things not
    >> in libc. I don't remember if any our dependencies pull in the threads
    >> library.
    >> I don't remember if glib always pulls in threads.
    >> If not, you could run into trouble if a non-threaded application used
    >> glib, pulled in threads via a plugin that also depended on glib and
    >> mutex or other state is inconsistent.
    >> 
    >> Similarly, we need to wkr if the application uses QT. Can you use glib
    >> and QT in the same application?

    Sam> Good points. I don't think there are many desktop apps on Linux that
    Sam> don't link to GLib already, and since GLib 2.24 GObject initialisation
    Sam> - 
    Sam> g_type_init() - has automatically initialised threads. Qt uses the
    Sam> GLib main event loop on Linux. So I don't think there is anything to
    Sam> worry about, but of course I can't promise without a list of the apps
    Sam> you will be linking to because there is always a corner case hiding
    Sam> somewhere.


Worst case: someone uses us for ldap authentication to something they
use as their nss passwd or group provider.
In that case we get linked into every application on the system.


    Sam> The one thing that could be an issue is if an app has been statically
    Sam> linked to a different version of GLib to the one on the
    Sam> system. However, this is a potential problem with any of your
    Sam> dependencies and is really a problem with the app.

I'd kind of hope that system dependencies would use version scripts and
symbol versions to support multiple versions of the library in the same
address space.  Getting that right for Kerberos was tricky.  The desktop
world seems to tolerate a lot more library churn than system libraries
do.
We'll see how bad this hurts in practice, but long term this is the kind
of thing that GSS mechanisms need to tolerate. However, I haven't vetted
other dependencies of the project against that sort of standard, so
don't worry about the multiple versions in the same process space issue
now.

    >> My suspicion is that it's probably fine to depend on glib, but someone
    >> familiar with glib implementation would need to consider the issue.
    >> 
    >> Since we're looking for a synchronous API, it seems like you could wrap
    >> your glib dependencies fairly easily.

    Sam> Yes, there's certainly no need to depend on GLib on Windows if we
    Sam> don't have to worry about asynchronicity.

    >> IN response to the MSVC support.  You need to produce an msvc compatible
    >> import library.  Your library needs to have an ABI that can be called
    >> from MSVC. (I think that means no C++ in your exposed ABI). Your public
    >> header file needs to be something that can be included from MSVC.
    >> 
    >> I don't think it is a requirement that your dll be buildable with MSVC,
    >> particularly if you build it as part of the existing moonshot-ui package
    >> which already requires mingw.  I don't think libtool in mingw mode
    >> produces import libraries, but I believe it's fairly easy to produce
    >> them from what it does build.

    Sam> Great, this is the easiest option. MSVC is required to produce
    Sam> MSVC-compatible import libraries from a dll, but it is not difficult.

I thought the mingw site had a procedure to turn a .a import library
plus a dll into a .lib. but it may have used msvc tools under the
covers.

Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

September 2017
August 2017
July 2017
May 2017
April 2017
March 2017
February 2017
December 2016
November 2016
October 2016
August 2016
July 2016
June 2016
May 2016
March 2016
February 2016
January 2016
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010


WWW.JISCMAIL.AC.UK

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager