3 ms·

I don't see what concurrency has to do with any of this. Concurrent Pascal was an interesting project for its time, heavily dated by now. The greatest victory

I don't see what concurrency has to do with any of this. Concurrent Pascal was an interesting project for its time, heavily dated by now. The greatest victory for concurrency was having architectures with thread-level parallelism instead of the dominant instruction-level parallelism, and one specifically optimized for CSP in the occam language. This was, of course, the transputer. So much for that. Erlang/OTP leads in the modern era. But I don't see any relation to our current topic of discussion.

nickpsecurity 11y ago
Server apps, including mail, implement forms of concurrency to handle incoming requests. Smart ones use either multi-threading or event model for performance. OpenBSD and others have all kinds of such apps they built on C. There have been numerous concurrency-related errors in major server apps due to this. So, just like with C itself, ignoring the safe, concurrency approaches from languages like Concurrent Pascal (or SCOOP/Eiffel today) is a failure to learn from the past with a direct, proven cost. Think all the race conditions, deadlocks, etc that have hit server apps would've happened on Solo, Ada tasking, or SCOOP? Probably fewer to none. So, it's still relevant and Ada/Eiffel are actually building on it. Especially SCOOP R&D community.
- vezzy-fnord 11y ago
  Oh, you're criticizing shared-state concurrency, I take it. Event loops seem to have been the norm for C projects for a while. Both OpenSMTPD and qmail seem to rely on concurrency through forkexec, which would entail deferring to the kernel's CPU scheduling and job control.
  - nickpsecurity 11y ago
    Yeah, specifically unsafe handling of it. Forkexec seems to be a heavyweight (and less portable) approach that even DJB defended in his paper. My gripe should apply to any using threads. "Event loops seem to have been the norm for C projects for a while." I'll take you word for it as I've seen that in the few, top-tier ones I scrutinized. There's a similar trail of research dealing with that alternate model. Have a feeling the meme might apply there, too, but won't accuse them until I see for sure. ;)

nickpsecurity 11y ago

Server apps, including mail, implement forms of concurrency to handle incoming requests. Smart ones use either multi-threading or event model for performance. OpenBSD and others have all kinds of such apps they built on C. There have been numerous concurrency-related errors in major server apps due to this. So, just like with C itself, ignoring the safe, concurrency approaches from languages like Concurrent Pascal (or SCOOP/Eiffel today) is a failure to learn from the past with a direct, proven cost. Think all the race conditions, deadlocks, etc that have hit server apps would've happened on Solo, Ada tasking, or SCOOP? Probably fewer to none. So, it's still relevant and Ada/Eiffel are actually building on it. Especially SCOOP R&D community.

vezzy-fnord 11y ago
Oh, you're criticizing shared-state concurrency, I take it. Event loops seem to have been the norm for C projects for a while. Both OpenSMTPD and qmail seem to rely on concurrency through forkexec, which would entail deferring to the kernel's CPU scheduling and job control.
- nickpsecurity 11y ago
  Yeah, specifically unsafe handling of it. Forkexec seems to be a heavyweight (and less portable) approach that even DJB defended in his paper. My gripe should apply to any using threads. "Event loops seem to have been the norm for C projects for a while." I'll take you word for it as I've seen that in the few, top-tier ones I scrutinized. There's a similar trail of research dealing with that alternate model. Have a feeling the meme might apply there, too, but won't accuse them until I see for sure. ;)