should I worry?

What does this mean:

"This function is a cancellation point in multi-threaded programs. This is a problem if the thread allocates some resources (like memory, file descriptors, semaphores or whatever) at the time read is called. If the thread gets canceled these resources stay allocated until the program ends. To avoid this, calls to read should be protected using cancellation handlers." (GNU)

I'm asking because I just mistook a failed recv in a fork for a symptom of such (the message: "bad address"/file descriptor, the real problem: unallocated buffer). I hadn't realized forking counts as multi-threading (but it does according to wikipedia).

If this is all true, what is the significance of the cancellation point?

What the hell... I thought my post had gone through. Well now you get a lazy post since I have to retype stuff.

fork() is for multi-threading. You can end up deadlocking threads. I wouldn't worry so much as be aware. And sometimes being aware means just making sure it doesn't happen instead of just hoping for the best.

Quote:

---

Originally Posted by master5001

What the hell... I thought my post had gone through. Well now you get a lazy post since I have to retype stuff.

---

sorry master5001 -- I reduced that post to "nevermind" after i realized it was the unallocated buffer (that "bad address" error is a real "red herring") and I guess the mod took it down.

Then I thought -- what if this is an issue anyway? So now I know, thanks.

I'm not sure what I thought "multi-threading" meant before but it if that's it, then it makes sense:)

Yeah its all good. I recall a time where I believe I should have known what multi-threading was and truly had no idea what it meant. Its just breaking up work. On a multi-CPU platform you can assign different work to different processors. Or on multi-core units you can assign different work to different cores. Or on fun systems with multi-core multi-processors, you can assign stuff all over the place.

In a more basic nutshell though it is just separating work. You may want a client to connect, but not have your program cease to respond to other clients while the new client is receiving some sort of response to their request. So you have a separate thread handle each client. That things aren't waiting for one another.

Now the kicker is that threads themselves can get stuck waiting around for one another.