Is OpenSMTPD worthy of OpenBSD inclusion?

Re:Is OpenSMTPD worthy of OpenBSD inclusion? by nickpsecurity on Monday October 05, 2015 @02:30PM (#10333753)

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.

[ Parent | on HN ]

Re:Is OpenSMTPD worthy of OpenBSD inclusion? by vezzy-fnord on Monday October 05, 2015 @02:37PM (#10333815)

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.

[ Parent | on HN ]

Re:Is OpenSMTPD worthy of OpenBSD inclusion? by nickpsecurity on Monday October 05, 2015 @02:45PM (#10333889)

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. ;)

[ Parent | on HN ]