linux - When is POSIX thread cancellation not immediate? -

the posix specifies 2 types thread cancellation type: pthread_cancel_asynchronous, , pthread_cancel_deferred (set pthread_setcanceltype(3)) determining when pthread_cancel(3) should take effect. reading, posix manual pages not these, linux manual page says following pthread_cancel_asynchronous:

the thread can canceled @ time. (typically, canceled upon receiving cancellation request, system doesn't guarantee this.)

i curious meaning the system doesn't guarantee this. can imagine happening in multicore/multi-cpu systems (before context switch). single core systems:

1. could have thread not cancelled when cancellation requested , cancellation enabled (pthread_setcancelstate(3)) , cancel type set pthread_cancel_asynchronous?
2. if yes, under conditions happen?

i curious linux (linuxthreads / nptl), more posix standard compliant way of viewing cancellation business.

update/clarification: here real practical concern usage of resources destroyed after calling pthread_cancel() targeted thread have cancellation enabled , set type pthread_cancel_asynchronous!!! point is: there tiny possibility cancelled thread in case continue running after context switch (even small time)?

thanks damon's answer question reduced signal delivery , handling in relation next context switch.

update-2: answered own question point bad concern , underlying program design should addressed in fundamentally different conceptual level. wish "wrong" question useful others wondering mysteries of asynchronous cancellation.

the meaning says: it's not guaranteed happen instantly. reason "liberty" implementation details needed , accounted in standard.

for example under linux/nptl, cancellation implemented sending signal nr. 32. thread cancelled when signal received, happens @ next kernel-to-user switch, or @ next interrupt, or @ end of time slice (which may accidentially immediately, but not). signal never received while thread isn't running, however. real catch here signals not received immediately.

if think it, isn't possible different, either. since can phtread_cleanup_push handlers operating system must execute (it cannot blast thread out of existence!), thread must run cancelled. there no guarantee any particular thread (including 1 want cancel) running @ exact time cancel thread, there can no guarantee cancelled immediately.
except of course, hypothetically, if os implemented in way block calling thread , schedule to-be-cancelled thread executes handlers, , unblocks pthread_cancel afterwards. since pthread_cancel isn't specified blocking, utterly nasty surprise. inacceptable because of interfering wtih execution time limits , scheduler fairness.

so, either cancel type "disable", nothing happens. or, "enable", , cancel type "deferred", thread cancels when calling function listed cancellation point in pthreads(7).
or, "asynchronous", stated above, os "something" cancel thread deems appropriate -- not @ precise, well-defined time, "soon". in case of linux, sending signal.