If there are real-time constraints, an RTOS has to be used, not Linux. OSEK is as an example of an open automotive RTOS, which is able to cope with hundreds of messages coming from buses in real-time manner and which is widely used.
The current automotive 'multimedia' ECUs (camera systems , satnavs, not head units), usually consist of a 'host' processor and a 'main' processor. The host processor is connected to CAN bus, running an RTOS (OSEK) and offloads handling of all real-time events, the main processor does the actual job.
The number of messages passed to the main processor can be still high - steering angle, speed or PDC distance (4 sensors+) could be updated every 40-50ms, plus a lot of internal events - new camera frames, data from GPS, gyroscopes, RDS etc.
Linux is not in a bad position as it might seem here. The complexity of our SW has grown enormously during the last few years, as well as the networking topology in cars and I feel that the way, how I have designed applications so far, is not possible any more. The fact that RTOSes mostly use only threads, sharing the same memory space without any protection, is a source of many delivery delays. A solution is to use a mature operating system and where it makes sense to split the application into isolated parts (processes).
I would need to handle ~400 events per second in time frame <~250us, the rest are interrupt driven things and given the architecture and the speed of processors planned for future projects, Linux can do that and a suitably designed messaging system would help a lot.
Anyway, time to move on something else.