Not really. The "cooperative multitasking" does NOT require kernel interrupting the work and usually has no policy -against- tasks going over their assigned timeframe. The idea is that OS hands over the control over the system to a task, the task recovers its context (as it's done on task level, the context may be minimized to required by that particular task, no need to store/recover variables the task never uses or temporaries that don't need to be stored between calls), performs a few iterations of its main loop, just enough to fit in the timeframe, then stores its content and exits back to OS which picks the next task. The kernel is really minimal as it doesn't do any of context switching or IO stuff, just calling tasks. Each of them is exclusive in their timeframe, no fear of other task kicking in, so you can safely i.e. use some port, send your messages, close it and hand the control over to the next task. Just free all the shared resources before continuing, or in some commonly agreed way mark them as used.

The advantages - it's much easier because task switching is performed at particular, strictly defined places convenient for each task.

Disadvantages - one task crashes, never returns, all crashes. One task takes 99.9% of CPU time, no way to stop it from doing so.

It's a really good way to do things if you write your OS and applications yourself, because the applications need to be written in a very specific way (on first call init, then after each call just perform a little bit of the work and return) but it's much lighter on the kernel which could then easily consist just of a loop filled with LCALLs.
For a true OS you need to write something that freezes a running task in its run, no matter where it is currently, stores all of its variables (because after recovering them, the task won't be aware that it had been interrupted, and OS doesn't know what the task needed to save and what was just an old junk) etc, etc.