From: Hiromichi Watari Date: May 4 2011 12:08am Subject: Re: Use of thread specific data with mysqld List-Archive: http://lists.mysql.com/internals/38316 Message-Id: <557740.58952.qm@web121510.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Mats, Thank you for your email, I've been working with 5.5 source code for a whil= e, when I get around to 6.0 I'll try to remember what you have indicated he= re. Thanks, Hiromichi --- On Tue, 5/3/11, Mats Kindahl wrote: > From: Mats Kindahl > Subject: Re: Use of thread specific data with mysqld > To: internals@stripped > Date: Tuesday, May 3, 2011, 5:31 AM > On 04/28/2011 02:41 AM, Hiromichi > Watari wrote: > > Hi Marc, > > Thank you very much for your pointer, I believe I'm OK > with my data residing in struct st_my_thread_var with the > common key THR_KEY_mysys for now.=A0 However if the need > changes in the future I will definitely take a look at what > you have done.=A0 I appreciate you taking time to answer > my question. > > Hiromichi >=20 > Hi Hiromichi, >=20 > A general note on storing data for a thread using > pthread_setspecific > in MySQL: it only works if there is a single THD associated > with each > thread. There were, for example, an experimental thread > pool > implementation in an 6.0 of the server trees where each > POSIX thread > managed several THD "session threads". If this architecture > is used, > it means that thread-specific data set using > pthread_setspecific can > "leak" to a different session if the same thread switches > to use a > different THD structure. >=20 > This is not the case unless you use 6.0, but since that > never GA:ed, > it should not be a problem in production environments since > the 5.1 > server has one THD structure for each POSIX thread. >=20 > Just my few cents, > Mats Kindahl > > > > --- On Wed, 4/27/11, Marc Alff > wrote: > > > >> From: Marc Alff > >> Subject: Re: Use of thread specific data with > mysqld > >> To: internals@stripped, > hiromichiwatari@stripped > >> Cc: "Sergei Golubchik" > >> Date: Wednesday, April 27, 2011, 1:14 AM > >> > >> Hi Hiromichi > >> > >> The performance schema also uses it's own thread > local > >> storage, with a dedicated thread key. > >> > >> Examples of code from storage/perfschema/*.cc: > >> > >> Init: > >> > >>=A0=A0=A0if > (pthread_key_create(&THR_PFS, > >> destroy_pfs_thread)) > >>=A0 =A0=A0=A0return NULL; > >> > >>=A0=A0=A0THR_PFS_initialized=3D true; > >> > >> Anything between init and destroy: > >> > >> PFS_thread *pfs_thread=3D > >> my_pthread_getspecific_ptr(PFS_thread*, THR_PFS); > >> my_pthread_setspecific_ptr(THR_PFS, pfs); > >> > >> Destroy: > >> > >>=A0=A0=A0/* > >>=A0 =A0=A0=A0Be careful to not delete > un-initialized > >> keys, > >>=A0 =A0=A0=A0this would affect key 0, > which is > >> THR_KEY_mysys, > >>=A0=A0=A0*/ > >>=A0=A0=A0if (THR_PFS_initialized) > >>=A0=A0=A0{ > >>=A0 > =A0=A0=A0my_pthread_setspecific_ptr(THR_PFS, > NULL); > >>=A0 > =A0=A0=A0pthread_key_delete(THR_PFS); > >>=A0 =A0=A0=A0THR_PFS_initialized=3D > false; > >>=A0=A0=A0} > >> > >> Note the code around THR_PFS_initialized: this was > found > >> the hard way, destroying a key that was not > properly created > >> caused all sort of chaos, so calls to > pthread_key_create() > >> and pthread_key_delete() have to be *really* well > balanced. > >> > >> I hope this helps. > >> > >> Regards, > >> -- Marc > >> > >> > >> On 4/26/11 1:19 PM, Hiromichi Watari wrote: > >>> Hi Sergei, > >>> I tried but I just couldn't make my own > thread > >> specific data to coexist with structure > st_my_thread_var so > >> I ended up moving my data to the structure and > used it > >> instead. > >>> I suppose there is really no reason to > reinvent the > >> wheel, is there ? > >>> But anyway, thank you for your help and you > are the > >> best. > >>> Hiromichi > >>> > >>> > >>> --- On Sun, 4/24/11, Sergei Golubchik >=20 > >> wrote: > >>>> From: Sergei Golubchik > >>>> Subject: Re: Use of thread specific data > with > >> mysqld > >>>> To: "Hiromichi Watari" > >>>> Cc: internals@stripped > >>>> Date: Sunday, April 24, 2011, 5:04 PM > >>>> Hi, Hiromichi! > >>>> > >>>> On Apr 24, Hiromichi Watari wrote: > >>>>> Hi, > >>>>> I'm trying to use thread specific data > with > >> mysqld but > >>>> ran into a problem with my_errno > generating > >> Segmentation > >>>> fault at the following line. > >>>>> I know that my_errno is also thread > specific > >> data but > >>>> not familiar with its implementation. > >>>>> I'm using pthread_key_create(), > >> pthread_setspecific() > >>>> and pthread_getspecific() for my own > thread > >> specific data, > >>>> is there something I should be aware of ? > >>>>> Thanks, > >>>>> Hiromichi > >>>>> > >>>>> p.s. I ran into this problem only if I > try to > >> use my > >>>> own thread specific data, of course. > >>>> > >>>> probably you forgot to call > my_thread_init() in > >> the > >>>> beginning of your > >>>> thread function. > >>>> > >>>> Anyway, here's the code: > >>>> > >>>> #define my_errno > my_thread_var->thr_errno > >>>> > >>>> #define my_thread_var (_my_thread_var()) > >>>> > >>>> struct st_my_thread_var > *_my_thread_var(void) > >>>> { > >>>>=A0 =A0=A0=A0return=20 > >> my_pthread_getspecific(struct > >>>> st_my_thread_var*,THR_KEY_mysys); > >>>> } > >>>> > >>>> my_bool my_thread_init(void) > >>>> { > >>>>=A0 =A0=A0=A0... > >>>>=A0 =A0 =A0=A0=A0if (!(tmp=3D > (struct > >> st_my_thread_var *) > >>>> calloc(1, sizeof(*tmp)))) > >>>>=A0 =A0 =A0=A0=A0{ > >>>>=A0 =A0 =A0 > =A0=A0=A0error=3D 1; > >>>>=A0 =A0 =A0 =A0=A0=A0goto > end; > >>>>=A0 =A0 =A0=A0=A0} > >>>>=A0 =A0 =A0=20 > >> pthread_setspecific(THR_KEY_mysys,tmp); > >>>>=A0 =A0=A0=A0... > >>>> } > >>>> > >>>> Regards, > >>>> Sergei > >>>> > >> >=20 >=20 > --=20 > MySQL Internals Mailing List > For list archives: http://lists.mysql.com/internals > To unsubscribe:=A0 =A0 http://lists.mysql.com/internals?unsub=3Dhiromichi= watari@stripped >=20 >