[odb-users] Use of thread local storage in ODB

[Andrew Cunningham]

I know the pain of having an app rejected for no good reason (an app that
does not use ODB..).

The good news is that you have the source to libodb and can build a version
without TLS.

If you look at the source you will find ODB_TLS_POINTER is only used in
transaction.cxx and session.cxx and is used to find the
"current_transaction" and "current_session" for the "current_thread".

I can think of many solutions. You could for example have a non TLS static
std::map that contains a thread_id as the key, and the transaction * as the
value, and the static current(),has_current() functions just lookup the
std::map using the current thread_id.

 Obviously would need std::mutex around insert and remove of the std::map
values for thread safety as a thread could be looking up the
current_transaction while another was inserting/removing from the map





On Sat, Sep 3, 2016 at 11:58 AM, Hales, Steve <Steve.Hales at garmin.com>
wrote:

> Yes, our app does run simultaneous transactions in multiple threads.
> Regarding the use of another mechanism instead of __thread do you have any
> suggestions for how to do that? We have gotten a human involved at Apple
> but they tend to be rather intransigent about these things. A number of
> developers have complained on-line about Apple’s prohibition against
> __thread and Apple has announced that Xcode 8 will support the thread_local
> modifier introduced in C++11. We are up against a schedule deadline on this
> and would be most appreciative of any guidance you can provide. If it
> matters, we are using sqlite as our backing database with ODB.
>
> Thanks,
> Steve
>
> From: <admin at a-cunningham.com> on behalf of Andrew Cunningham <
> odb at a-cunningham.com>
> Date: Saturday, September 3, 2016 at 11:35 AM
> To: "Hales, Steve" <Steve.Hales at garmin.com>
> Cc: "odb-users at codesynthesis.com" <odb-users at codesynthesis.com>
> Subject: Re: [odb-users] Use of thread local storage in ODB
>
> It depends on whether your app is running transactions in multiple
> threads. ODB has a concept of the "current transaction"  and the "current
> session" which are  variables that are TLS ( local to a thread).
> You might need to come up with another mechanism if you can't use the
> standard __thread.
>
> I would protest to Apple about rejecting your app. I can't see how
> compiling against "public" POSIX threading API's could be seen as using
> private APIs. Apple , of course, uses some automatic scanning of the app,
> maybe get a human involved.
>
>
> On Fri, Sep 2, 2016 at 4:54 PM, Hales, Steve <Steve.Hales at garmin.com>
> wrote:
>
>> My team has created an iOS app that uses ODB. We recently submitted the
>> app to Apple to be published in the app store. Our app was rejected due to
>> the presence of the symbol "__tlv_bootstrap" which Apple considers to be
>> part of an unapproved private API. Our research indicates that this symbol
>> results from use of the "__thread" modifier to create a thread local
>> variable. The only place we can find __thread in our code is in the ODB
>> header tls.hxx where it appears to take effect when POSIX threads are
>> enabled. When we built the ODB library for our app we specified
>> --enable-threads in the configure step. Can you tell us if that header,
>> specifically the __thread use, is likely to be included in our code? If so,
>> would rebuilding ODB with threads disabled remove it? And what effect might
>> that have on our app?
>>
>> Thanks,
>> Steve
>>
>> ________________________________
>>
>> CONFIDENTIALITY NOTICE: This email and any attachments are for the sole
>> use of the intended recipient(s) and contain information that may be Garmin
>> confidential and/or Garmin legally privileged. If you have received this
>> email in error, please notify the sender by reply email and delete the
>> message. Any disclosure, copying, distribution or use of this communication
>> (including attachments) by someone other than the intended recipient is
>> prohibited. Thank you.
>>
>
>