El Mon, 17 Aug 2009 14:33:42 +0400 Peter Zotov <[email protected]> escribió: > As embedded linux developer I can say that POSIX message queues are > rarely turned on in these kernels, so it's not a very good option. > (I personally always turn it off ;) and there are many places where > you can't just recompile kernel, e.g. motorola proprietary kernel > builds or N770 or something similar).
I don't care much about that because we can't support those restricted environments anyway. BTW, on Linux, POSIX mq is a very lightweight feature, in-memory footprint is 6.3k, and gzipped it's 3.3k. Back to the topic: We have two concerns here: performance and ease of use. Given our event-based nature, POSIX message queues can provide a much cleaner implementation. It greatly simplifies the design because the "connection" concept vanishes, and there's no interaction required to receive the data nor to manage it until it's really needed. OTOH, it should perform better than a socket too (not taking into account the reduced complexity which also helps). The main problem is: how do we send the response back to the client? Using another queue on the client side allows to receive an answer via another subsystem implemented by a different program without proxying. Later we may implement such distributed model if proves to be useful. Also consider that on Linux message queues don't live on the filesystem, so no SIGHUP is needed after replacing /dev :). But there might be problems related to message queues that I'm not taking into account... -- Ismael Luceno
signature.asc
Description: PGP signature
-- _______________________________________________ Initng mailing list [email protected] http://jw.dyndns.org/mailman/listinfo/initng
