On Wed, Oct 21, 2009 at 8:38 AM, Phil Dawes <[email protected]> wrote: > Hi Slava, > > I've written initial os-thread mutex and semaphore FFIs in > extra:concurrency.locks.unix and concurrency.locks.windows,
Good stuff. > and was just > about to wrap it together into a unified api when I realised > concurrency.locks was already used for cooperative threads. You didn't even know this existed? Please take a look at what's there so you can at least have some ideas on how to structure your API. > - Should there be a totally separate concurrency package for os threads? Yes, extra/concurrency/native is OK for now. > - From an API perspective do you plan to distinguish between cooperative > and os-threads in the brave new factorMT world? Yes, because for the forseeable future, we're going to have co-operative threads sharing a VM, with multiple native threads each running their own VM. Totally different semantics. For instance, native locks will need to go into unmanaged memory and be disposed with destructors. Having said that, do try to keep the APIs as similar as possible. Long-term, there might be some unification going on, but for now, since you're not making Factor really have native threads, just the ability to run multiple VMs, they will remain totally distinct. Slava ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Factor-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/factor-talk
