Here's one approach to address what you seem to want to do.
Given that the interrupt demand of the LED update(~30 us per LED, more or less, * the number of LEDs in series) is too much to tolerate for your main processor, which is doing 'something else'. Have your LED string controller simply wait for a complete block of data, update the LEDs with it, and drop back into the wait.
Your main controller then goes about it's business, and sends a block of data to the LED controller when it wants to - but it does need to know the LED controller is 'waiting for more', so some query is needed.
Something like this would evolve:
Main controller - "Are you ready?"
LED controller - "Yes"
Main controller -
LED controller - /
Main controller repeats "Are you ready", if nak was sent.
if ack was sent, both go about their business
But again, the main advantage here is that the main controller needn't suffer the long sustained interrupt structure of the pixel update(which only ever happens with show() anyway), but then needs to transfer (3*n plus a few) bytes whenever the pixels need updating.
In one case I'm working on, the main controller would only ever be changing one or two LEDs at a time, to one of 6 colours, so this becomes much more feasible - the traffic on the serial bridge is very light, so it becomes quite easy to see benefits from offloading the pixel update to a 'Tiny operating as 'LED coprocessor'. Any update would be "update pixel with colours <x,y,z>", but might take the form of . An 8 byte message where
stx - traditional 'start transmission' character
cc - a single character command
* could be any number of commands. Reset, dim all by 10%, dim all
* to 10%, fade over duration, etc. YMMV
nn - an LED designator, from 0->255, if the context of the command needs it
rrggbb - three byte colour set for an LED, again, if the context needs it
checksum - simply the 8-bit sum of the previous bytes(traditionally, omits stx)
etx - traditional end of transmission character
and the controller simply replies ACK or NAK
ETX, STX, ACK, NAK are all traditional characters in the ASCII chart.
substitute at will, it's just a concept.