I did a forum search but it didn't seem like this has been mentioned.

So... I'm starting a project where the delay time for vTaskDelayUntil will be variable and could be really short.

If the delay until time (xLastWakeTime plus xPeriod in your example) generates an end time that has already past, does this return immediately (good) or wait for the clock to roll over (bad) crash (worse)?

Example:

{wakeup}
xLastWakeTime is set to 1000
{ do things that take 2 ticks }
xPeriod = 1;
vTaskDelayUntil( &xLastWakeTime, xPeriod );
// the wakeup time is now 1001 but the clock time is 1002.

I guess I have one more question, is the xLastWakeTime now 1001 or 1002? ie: is it the calculated wakeup time or the time it actually woke up?

I wrote some test code for to try this out. To simulate a busy system I made a loop with vTaskDelay(2); in front of the vTaskDelayUntil. I used a variable for xPeriod and with the debugger kept decreasing it to see what it would do.

With xPeriod of 2 or higher, the period WAS 2.
With xPeriod of 1 the period was still 2, so instant return (good work!)
With xPeriod of 0, the system hangs. I can live with that.

So, as long as I verify xPeriod is greater than zero, I don't need to worry about this low priority task crashing when the system gets busy.

If you step into the function you will see near the top an assert to trap 0 being passed in.