On Wednesday 02 August 2006 12:51, Martin Pohlack wrote:
Christian Helmuth wrote:
Hello David,
On Tue, Aug 01, 2006 at 04:55:53AM -0700, David Silcott wrote:
I've ported my multithreaded tcp server to L4 using flips but I am having some problems getting it to run properly. It is a quite a bit to explain so I've written a simple tcp echoserver to demonstrate my problem.
Ouch, already at this point I remember some limitations of the FLIPS experiment and L4VFS. FLIPS supports concurrent blocking RPCs, e.g. send() and recv(), only for calls using different L4VFS connections, see l4vfs_init_connection(). If one uses the same connection for two blocking calls the latter one is blocked in the underlying IPC in the microkernel.
L4VFS currently implements no extensive multi-threading support and therefore initializes only one connection to FLIPS per task, see l4/pkg/l4vfs/lib/libc_backends/socket_io/socket.c line 44 ff.
L4VFS *does* support multithreading applications, for example with the term server. Therefore many functions in the IDL interfaces have this [allow_reply_only] flag set which basically allows the server to not answer calls directly but delayed with the help of a worker thread. In between the session thread in the server is ready to receive new calls.
A small note: It is true that the answer can be delayed by the server, however, the genereated code for L4v2 clients generated by the current DICE implementation uses l4_ipc_call on the client side. Therefore the very same thread which received the request has to reply (as long as "send-as" is not implemented).
Frank