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@lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev