It's not as if the design alternative you're suggesting --- ie, storing "struct-proc-star" all over the place --- is much safer. You still have to track down and invalidate every stale "struct-proc-star" when you delete from the list. And this notion of having to store a base pointer and the pointer --- you're storing the identity of the collection somewhere. I think this is a straw man.
If you have a collection where random deletion is central to the design, then by all means, use a list. The process table is perhaps one example.
But just because you might at some point need random deletion doesn't mean it's a win to use a linked list. The process table will constantly have random deletions, but pid 47481 is far more likely to die at any moment than pid 10. Do you know how not-expensive it is to memcpy 1-3 "struct procs"? How often is the process table indexed or traversed? Roughly every 10th scheduling quantum? Are you sure you're optimizing for the right thing?
Incidentally, if you need FIFO behavior, a ring buffer is a nice thing to have in your toolchest.
If you have a collection where random deletion is central to the design, then by all means, use a list. The process table is perhaps one example.
But just because you might at some point need random deletion doesn't mean it's a win to use a linked list. The process table will constantly have random deletions, but pid 47481 is far more likely to die at any moment than pid 10. Do you know how not-expensive it is to memcpy 1-3 "struct procs"? How often is the process table indexed or traversed? Roughly every 10th scheduling quantum? Are you sure you're optimizing for the right thing?
Incidentally, if you need FIFO behavior, a ring buffer is a nice thing to have in your toolchest.