For hibernation it behaves the same as on other types of systems.
For STR it generally works okay. There was one report of suspends
aborting, and it looked like this was caused by selective resumes
originating from userspace. This seemed to be unrelated to the kernel
threads; apparently some program was running while the STR was in
progress, and causing the problem. For example, the lsusb program will
do a selective resume on every USB device as it scans through them all.
However that's just a guess, we haven't fully resolved that bug report.
The theoretical answer is that it behaves the way we want. The kernel
thread does selective resumes in response to device requests. If such
a request comes in while the system is asleep it will awaken the
system; so it's only logical that a request coming in while the system
is in the process of going to sleep should abort the suspend.