Re: [AD] Get thread id

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On Fri Aug 17, 2012, Dimitris Zenios wrote:
> On Sat, Aug 18, 2012 at 3:32 AM, Thomas Fjellstrom
> 
> <tfjellstrom@xxxxxxxxxx> wrote:
> > On Fri Aug 17, 2012, Dimitris Zenios wrote:
> >> Sure i know how a good thread safe function should be.As i said above
> >> is not for my program, but from the discussion is seems that we are
> >> trying to avoid something by saying that its "bad design / bad
> >> practice".Yeah of course is bad bad bad bad very bad  think to call a
> >> function from multiple threads if its not thread safe but by having a
> >> thread id someone can assure this.Maybe there are other reasons for
> >> someone to get a thread id (Nothings comes in mind though)
> > 
> > But you're modifying this function to check for the thread id right? Why
> > not just add a lock or two while you're in there?
> 
> Nope i don't have such a function.Because i am coming from SDL
> background i saw that SDL supported it and i said why not Allegro
> also.

Ah. I thought you needed it to work with some existing code that isn't thread 
safe.

> >> As i said, i am not dying for this function to be added.I though it
> >> will be a nice addition that's the reason i created a patch.It can be
> >> skipped though.
> > 
> > It has its uses.
> 
> As you said it has its uses.Maybe not many but its still something
> that it might be useful.
> 
> >> On Sat, Aug 18, 2012 at 3:13 AM, Thomas Fjellstrom
> >> 
> >> <tfjellstrom@xxxxxxxxxx> wrote:
> >> > On Fri Aug 17, 2012, Thomas Fjellstrom wrote:
> >> >> On Fri Aug 17, 2012, Dimitris Zenios wrote:
> >> >> > Its not for my program but i think there are cases that you have to
> >> >> > be sure that a function is not called from another thread other
> >> >> > than the main.Also sanity checks etc.In my opinion i think is
> >> >> > something good for the library to supply.If not possible at the
> >> >> > moment or difficult to implement in a safe way then it can be
> >> >> > skipped.
> >> >> 
> >> >> Well generally you just don't call functions from multiple threads if
> >> >> they shouldn't be called. If you do need/want to call the same
> >> >> function from multiple threads, the code needs to be fully
> >> >> reentrant. Generally thats done with locks/mutexes, or just not
> >> >> depending on global state or having any race conditions (writing
> >> >> from two separate threads? reading from one writing in the other?).
> >> >> (or fancy lockless algorithms)
> >> > 
> >> > Derp moment. reentrant != thread safe. You want your code to be thread
> >> > safe.
> >> > 
> >> >> > On Sat, Aug 18, 2012 at 2:57 AM, Peter Wang <novalazy@xxxxxxxxxx> 
wrote:
> >> >> > > On Sat, 18 Aug 2012 02:43:06 +0300, Dimitris Zenios
> >> >> 
> >> >> <dimitris.zenios@xxxxxxxxxx> wrote:
> >> >> > >> >From my previous email. get thread id would be an easy way to
> >> >> > >> >check if
> >> >> > >> 
> >> >> > >> the function was called from the main thread or not.
> >> >> > > 
> >> >> > > But why is your program designed like that?
> >> >> > > 
> >> >> > > Peter
> >> >> > > 
> >> >> > > -----------------------------------------------------------------
> >> >> > > --- --- -- ----- Live Security Virtual Conference
> >> >> > > Exclusive live event will cover all the ways today's security and
> >> >> > > threat landscape has changed and how IT managers can respond.
> >> >> > > Discussions will include endpoint security, mobile security and
> >> >> > > the latest in malware threats.
> >> >> > > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ --
> >> >> > > https://lists.sourceforge.net/lists/listinfo/alleg-developers
> >> >> > 
> >> >> > -------------------------------------------------------------------
> >> >> > --- --- -- --- Live Security Virtual Conference
> >> >> > Exclusive live event will cover all the ways today's security and
> >> >> > threat landscape has changed and how IT managers can respond.
> >> >> > Discussions will include endpoint security, mobile security and the
> >> >> > latest in malware threats.
> >> >> > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> >> > 
> >> > --
> >> > Thomas Fjellstrom
> >> > tfjellstrom@xxxxxxxxxx
> >> > 
> >> > ----------------------------------------------------------------------
> >> > --- ----- Live Security Virtual Conference
> >> > Exclusive live event will cover all the ways today's security and
> >> > threat landscape has changed and how IT managers can respond.
> >> > Discussions will include endpoint security, mobile security and the
> >> > latest in malware threats.
> >> > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ --
> >> > https://lists.sourceforge.net/lists/listinfo/alleg-developers
> >> 
> >> ------------------------------------------------------------------------
> >> --- --- Live Security Virtual Conference
> >> Exclusive live event will cover all the ways today's security and
> >> threat landscape has changed and how IT managers can respond.
> >> Discussions will include endpoint security, mobile security and the
> >> latest in malware threats.
> >> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > 
> > --
> > Thomas Fjellstrom
> > tfjellstrom@xxxxxxxxxx
> > 
> > -------------------------------------------------------------------------
> > ----- Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond. Discussions
> > will include endpoint security, mobile security and the latest in malware
> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > --
> > https://lists.sourceforge.net/lists/listinfo/alleg-developers
> 
> ---------------------------------------------------------------------------
> --- Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/


-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/