3 ms·

> With all due respect, "Epic troll. Bravo." > someone who claims to have embedded experience shouldn't have to ask hacker news about the benefits of fork, un

by billpg 17y ago

> With all due respect, "Epic troll. Bravo." > someone who claims to have embedded experience shouldn't have to ask hacker news about the benefits of fork, unless your embedded experience is all on Windows Mobile and its ilk, where CreateProcess rules the day. Why do I feel an urge to defend my experience to someone who openly insults me? I should just walk away. (sigh) I've worked on OS-less systems, where we have a short bit of assembly to pass control over to the "Main" function written in C. We implement concurrency by hooking into the timer-tick interrupt. I'd describe those as having two shared memory threads, one pre-emptive and one co-operative. As well as that, I've used psos and vxworks. These have pre-emptively switched processes, but I'd describe them as threads as they share memory and have no protection between them. There's no memory management or virtual memory, load memory location 42 and 42 comes out of the address bus.

clord 17y ago
I'm not trying to insult, but on re-reading I guess one can see it that way, what with the troll remark and all. You have to admit your post had most of the effects your typical internet troll's would. But on topic; your original post suggests that there are "simpler ways of starting a new process" and that using threads "seems far more useful with a lot less complications." I think this is wrong on both counts. There is no simpler way to start a process, and using threads leads people towards manually reproducing many of the things fork provides for free, leading to more complicated and difficult to understand code. I understand when the average programmer misunderstands fork, but systems programmers should know better. Since your experience is on the hardware level, and not operating systems, it makes more sense that you're not aware of the advantages of fork. But I still can not fathom what you consider to be more simple than fork. Perhaps your definition of process creation differs from mine, and most others? I'd like to understand more, in any case.

by billpg 17y ago

clord 17y ago

I'm not trying to insult, but on re-reading I guess one can see it that way, what with the troll remark and all. You have to admit your post had most of the effects your typical internet troll's would. But on topic; your original post suggests that there are "simpler ways of starting a new process" and that using threads "seems far more useful with a lot less complications." I think this is wrong on both counts. There is no simpler way to start a process, and using threads leads people towards manually reproducing many of the things fork provides for free, leading to more complicated and difficult to understand code. I understand when the average programmer misunderstands fork, but systems programmers should know better. Since your experience is on the hardware level, and not operating systems, it makes more sense that you're not aware of the advantages of fork. But I still can not fathom what you consider to be more simple than fork. Perhaps your definition of process creation differs from mine, and most others? I'd like to understand more, in any case.