[PD-dev] Improving portability of the thread management

Miller Puckette msp at ucsd.edu
Sat May 7 18:49:03 CEST 2016


OK.. no hurry on my end :)

M

On Sat, May 07, 2016 at 01:28:35PM +0200, Pierre Guillot wrote:
> Ok, for the moment my fake pthread API is a set of macro. It would be
> better that I clean a bit this part of the code. One way to use it would be
> to set up a preprocessor definition (something like WIN_USE_NATIVE_THREAD).
> This way, the devs must define explicitly the use of the Windows API.
> Nevertheless, I have to put this work on standby for the moment, I have got
> too much work to do and I don't want to introduce bugs because I rushed.
> Thanks !
> Pierre
> 
> 2016-04-30 20:29 GMT+02:00 Miller Puckette <msp at ucsd.edu>:
> 
> > After thinking for a while about this I think it's best if you try to fake
> > the cthreads API from the windows one...  if only because that way whatever
> > bugs get introduced will only manifest when using the rarer windows API.
> > (I live in fear of lurking thread-safety lapses which can cause crashes
> > that
> > are extremely hard to reproduce.)
> >
> > cheers
> > Miller
> >
> > On Sun, Apr 24, 2016 at 04:20:05PM +0200, Pierre Guillot wrote:
> > > PD uses the pthread library, but with MVC this can be really annoying.
> > The
> > > project pthread-win32 offers a dynamic version of the library for Windows
> > > but no static version. If you compile the static library, you have to
> > > change the code because there are linking problems with MVC. I think it
> > > would be better to use Windows thread system. The main problem comes from
> > > the file "d_soundfile.c". I made a small wrapper (
> > > https://github.com/pierreguillot/thread) and if you're interested I can
> > try
> > > to integrate this in PD. I have several questions before. Should I use a
> > > wrapper for pthread and "WinThread" or should I make a wrapper only for
> > > WinThread that allows to use the pthread function prototypes. I already
> > > have the two solutions. I don't know if the
> > sys_lock/sys_unlock/sys_trylock
> > > functions (in m_sched.c) are really necessary in a context like libpd.
> > The
> > > problem is that we can't have a static initializer for Windows critical
> > > sections, so we must use something like void sys_lock_init and
> > > sys_lock_destroy. For the moment, in my project I use the preprocessor
> > > definition THREAD_LOCKING=0 to avoid this part of the code but I think it
> > > would be better to enable this feature, in case someone uses it in an
> > > external.
> > >
> > > Cheers
> >
> > > _______________________________________________
> > > Pd-dev mailing list
> > > Pd-dev at lists.iem.at
> > > https://lists.puredata.info/listinfo/pd-dev
> >
> >



More information about the Pd-dev mailing list