The problem with reading a terminal character is what if it is supposed to be another int.
I have run into this problem because I am using strictly integers. There is no convenient way to check for that terminating character. I look for a starting character and do a for loop for x number of integers depending on what that starting character is. This also has the benefit of allowing me to have multiple RX in the buffer. I do this because I can conceivable receive 7 different types of serial data. So the starting character dictates both how many integers and what to do with the data once I've received it. So if I have data coming in from 3 differnt sources, they can all stack up in the buffer, I read each set out individually. I have yet to try this in a real world situation since so far I am only sending from the monitor.
To address the OP's problem, I can't see why the very first example wouldn't work correctly. If you send exactly one number with no starting or terminating character, it should read that as int and move on. When I send my streams, i do not terminate at all and I get what appears to be instant response. I am writing data to an LCD so there is a very slight delay.
I can see where it would hang if you sent a terminating character since as stated, it reads the int then in the next loop it sees the 'f' so it sees serial.available() and tries to read an int that isnt't there.
With the f still in the sent data, try to call a Serial.flush() right after you parseint and see what it does.