[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Concurrency, again

From: Philipp Stephani
Subject: Re: Concurrency, again
Date: Tue, 25 Oct 2016 13:27:39 +0000

John Wiegley <address@hidden> schrieb am Mi., 12. Okt. 2016 um 18:43 Uhr:
>>>>> "SM" == Stefan Monnier <address@hidden> writes:

SM> IOW, I completely agree with Eli: we should fix the few remaining issues
SM> with the concurrency branch and merge it into master.

I very strongly disagree. I think "merge what we have and make it work" is the
wrong approach.

I agree, there should at least be some more discussion about the design we want.
You could group the concurrency problem into a couple of subproblems:
- Context switching
- Scheduling
- Communication
- Synchronization
IIUC the concurrency branch uses OS threads plus custom code for context switching and scheduling, global variables for communication, and OS mutexes/condvars for synchronization. My experiment uses setcontext for context switching, a user mode scheduler for scheduling, and CSP without shared state for both communication and synchronization. I think CSP has the advantage of being higher-level and avoiding low-level bugs due to misuse of synchronization primitives such as mutexes.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]