hello...
I'm having a problem with the FLIPS server. I'm doing some transmission in TCP and i seems that the call from the client to the FLIPS server doesn't arrive. I've putten some printfs along the way in l4vfs_net_io_send_call and he does the call the IPC function... but i've putten also some debug message in l4vfs_net_io_send_component and it doesn't print out... so something is dying around here and i don't know where...:(
My questions are...
in the FLIPS/L4vfs net_io server side where should i put the debug to see if the call has arrived? (i've tried in net_io-server.c and nothing is shown)
i've sent something earlier trought that socket... i mean... it only dies when i try to send something the second time... am i missing something (the socket its the same it stays connected)?
is there any problem with FLIPS that prevents me from sending something from a socket that is blocked in a recv in another thread (should't be because TCP is bi-directional)?
thanks in advance
Tiago
Hello,
On Fri, Apr 29, 2005 at 04:55:31PM +0100, Tiago Jorge wrote: [...]
is there any problem with FLIPS that prevents me from sending something from a socket that is blocked in a recv in another thread (should't be because TCP is bi-directional)?
Unfortunately you're right. We implemented FLIPS session-based and one session can be used only for one blocking operation at a time. This comes from the design of dde_linux and Linux, where client threads must be represented as process threads (with task_struct and all) for native Linux kernel code.
A thread (process) that is enqueued in a wait queue calls schedule(). schedule() is implemented in a way that the L4 thread representing the Linux process blocks until woken up by a call to wake_up() or a similar operation. For your socket this means: If the session thread is blocked, then no further requests are processed on FLIPS side.
The L4VFS dietlibc backend may also be a spoiler here (not investigated further) as it may not support multiple server threads for one and the same file id.
Sorry for not helping you much, but I hope this clears things up.
Christian Helmuth wrote:
Hello,
On Fri, Apr 29, 2005 at 04:55:31PM +0100, Tiago Jorge wrote: [...]
is there any problem with FLIPS that prevents me from sending something from a socket that is blocked in a recv in another thread (should't be because TCP is bi-directional)?
Unfortunately you're right. We implemented FLIPS session-based and one session can be used only for one blocking operation at a time. This comes from the design of dde_linux and Linux, where client threads must be represented as process threads (with task_struct and all) for native Linux kernel code.
A thread (process) that is enqueued in a wait queue calls schedule(). schedule() is implemented in a way that the L4 thread representing the Linux process blocks until woken up by a call to wake_up() or a similar operation. For your socket this means: If the session thread is blocked, then no further requests are processed on FLIPS side.
The L4VFS dietlibc backend may also be a spoiler here (not investigated further) as it may not support multiple server threads for one and the same file id.
Sorry for not helping you much, but I hope this clears things up.
ok... maybe this is my problem regarding another thread in the hackers list... can this be solved using "select"? Because i must have a listen socket and a sending socket... so if my l4 server has a socket in a select wainting for input, should it be able to send throught another socket?
thanks
Tiago
ok... maybe this is my problem regarding another thread in the hackers list... can this be solved using "select"? Because i must have a listen socket and a sending socket... so if my l4 server has a socket in a select wainting for input, should it be able to send throught another socket?
following my last emails... i've tried with select and it doesn't work also. So... before a build a separate server just to relay my messages, is it possible to change the blocking state of a socket. I've seen that the l4vfs implementation of fcntl its just a dummy implementation so my question is... is it possible throught another l4vfs method or something in FLIPS to do non-blocking IO in sockets/file descriptors?
thaks for all your help
Tiago
Tiago Jorge wrote:
ok... maybe this is my problem regarding another thread in the hackers list... can this be solved using "select"? Because i must have a listen socket and a sending socket... so if my l4 server has a socket in a select wainting for input, should it be able to send throught another socket?
following my last emails... i've tried with select and it doesn't work also. So... before a build a separate server just to relay my messages, is it possible to change the blocking state of a socket. I've seen that the l4vfs implementation of fcntl its just a dummy implementation
Well, my fcntl() looks as follows:
int fcntl( int fd, int cmd, ... ) { file_desc_t fdesc; int ret; long arg; struct flock *lock; va_list list;
if (! ft_is_open(fd)) { errno = EBADF; return -1; }
fdesc = ft_get_entry(fd);
if (l4_is_invalid_id(fdesc.server_id)) { // should not happen errno = EBADF; return -1; }
lock = NULL;
va_start( list, cmd ); switch( cmd ) { case F_GETLK: case F_SETLK: case F_SETLKW: lock = va_arg( list, struct flock * ); break; case F_DUPFD: case F_SETFD: case F_SETFL: //case F_SETOWN: //case F_SETSIG: //case F_SETLEASE: //case F_NOTIFY: arg = va_arg( list, long ); break; default: // no arg arg = 0; break; } va_end( list );
// fixme: we don't need to call the server allways, e.g. for // F_DUPFD which works locally completely! others?
// now we can call the server if (lock) { // hmm. dice doesn't recognize struct flock definition in fcntl.h // ret = l4vfs_fcntl_flock(fdesc.server_id, // fdesc.object_handle, // cmd, // lock, // sizeof(*lock) ); LOG("F_GETLK, F_SETLK, F_SETLKW not supported"); ret = -EINVAL; } else ret = l4vfs_fcntl(fdesc.server_id, fdesc.object_handle, cmd, (l4_int32_t *) &arg ); return ret; }
I therefore do not consider it to be "dummy".
L4VFS is meant to be extended on a use-case basis, it has grown over the last 1 1/2 years as other projects utilized it. Maybe you have to extend it a little bit. We gladly accept patches (hint, hint).
L4VFS is not meant as a complete posix compliant multiserver unix replacement!
so my question is... is it possible throught another l4vfs method or something in FLIPS to do non-blocking IO in sockets/file descriptors?
You could open a file in nonblocking mode using open(..., O_NONBLOCK) if the corresponding server supports this.
Greets, Martin
Martin Pohlack wrote:
Tiago Jorge wrote:
ok... maybe this is my problem regarding another thread in the hackers list... can this be solved using "select"? Because i must have a listen socket and a sending socket... so if my l4 server has a socket in a select wainting for input, should it be able to send throught another socket?
following my last emails... i've tried with select and it doesn't work also. So... before a build a separate server just to relay my messages, is it possible to change the blocking state of a socket. I've seen that the l4vfs implementation of fcntl its just a dummy implementation
Well, my fcntl() looks as follows:
int fcntl( int fd, int cmd, ... ) { file_desc_t fdesc; int ret; long arg; struct flock *lock; va_list list;
if (! ft_is_open(fd)) { errno = EBADF; return -1; }
fdesc = ft_get_entry(fd);
if (l4_is_invalid_id(fdesc.server_id)) { // should not happen errno = EBADF; return -1; }
lock = NULL;
va_start( list, cmd ); switch( cmd ) { case F_GETLK: case F_SETLK: case F_SETLKW: lock = va_arg( list, struct flock * ); break; case F_DUPFD: case F_SETFD: case F_SETFL: //case F_SETOWN: //case F_SETSIG: //case F_SETLEASE: //case F_NOTIFY: arg = va_arg( list, long ); break; default: // no arg arg = 0; break; } va_end( list );
// fixme: we don't need to call the server allways, e.g. for // F_DUPFD which works locally completely! others?
// now we can call the server if (lock) { // hmm. dice doesn't recognize struct flock definition in fcntl.h // ret = l4vfs_fcntl_flock(fdesc.server_id, // fdesc.object_handle, // cmd, // lock, // sizeof(*lock) ); LOG("F_GETLK, F_SETLK, F_SETLKW not supported"); ret = -EINVAL; } else ret = l4vfs_fcntl(fdesc.server_id, fdesc.object_handle, cmd, (l4_int32_t *) &arg ); return ret; }
I therefore do not consider it to be "dummy".
L4VFS is meant to be extended on a use-case basis, it has grown over the last 1 1/2 years as other projects utilized it. Maybe you have to extend it a little bit. We gladly accept patches (hint, hint).
;)... ok i've understood the hint. but the dummy i've talked about was the implementation of l4vfs_*_fcntl_component(...). that is the implementation of the dielibc... bue when it calls the server side function it's not implemented. my question was if in one of those projects someone implemented it
thanks again
Tiago
L4VFS is not meant as a complete posix compliant multiserver unix replacement!
so my question is... is it possible throught another l4vfs method or something in FLIPS to do non-blocking IO in sockets/file descriptors?
You could open a file in nonblocking mode using open(..., O_NONBLOCK) if the corresponding server supports this.
Greets, Martin
<fcntl snipped>
I therefore do not consider it to be "dummy".
L4VFS is meant to be extended on a use-case basis, it has grown over the last 1 1/2 years as other projects utilized it. Maybe you have to extend it a little bit. We gladly accept patches (hint, hint).
;)... ok i've understood the hint. but the dummy i've talked about was the implementation of l4vfs_*_fcntl_component(...). that is the implementation of the dielibc...
This has *nothing* to do with the dietlibc!
bue when it calls the server side function it's not implemented.
Your are quite unprecise with your statements. Which fcntl do you mean? Are you talking about l4vfs/lib/server/fcntl.c? This is the weak implementation of the server lib. Every server which implements fcntl() functionality shall provide its own impl. overriding this weak dummy impl.
I think you now know were to start coding ...
my question was if in one of those projects someone implemented it
I dont know of any such thing.
Greets, Martin
Hello,
On Mon, May 02, 2005 at 08:30:04PM +0100, Tiago Jorge wrote:
ok... maybe this is my problem regarding another thread in the hackers list... can this be solved using "select"? Because i must have a listen socket and a sending socket... so if my l4 server has a socket in a select wainting for input, should it be able to send throught another socket?
Again, I'm not sure what your scenario looks like. You need a listen socket L and a socket for sending S, right? Do you implement a TCP server with accept()? I'm asking since you talked about UDP communication in earlier emails.
Anyway, your server blocks on L and afterwards you want your server to send via S? A simple answer is: Deblock your server via a network packet or any other action on a file (as you said you use select()). Then your server is no longer blocked on an fd_set containig L and can send via S.
If this is not your favourite solution you have three choices:
1) Give us a detailed description of your scenario so we have a chance to help you. 2) Implement a really multi-threaded server with dietlibc and L4VFS, in which thread A can block on L while thread B sends via S. Post your experiences and ask questions backgrounded with sufficient information about the scenario and used functions. 3) Help yourself.
Greets
Christian Helmuth wrote:
- Implement a really multi-threaded server with dietlibc and L4VFS, in
which thread A can block on L while thread B sends via S. Post your experiences and ask questions backgrounded with sufficient information about the scenario and used functions.
My solution is to have somekind of a pool using non-blocking select. if it has input then he does the recvfrom else sleeps for a period of time and the checks again for input. Ths other solution was to have a L4 server to relay messages... but then i would also have the IPC overhead... so i went to the solution above.
thanks for the help
Tiago
After some local discussions I want to make some concluding remarks to this issue:
I see two possible solutions to the problem of missing parallelity in L4VFS / flips.
1. Solve it as it is done in "term_server", i.e., use one distributor thread receiving and replying to all request in flips. This thread simply forwards all work to a set of worker threads. This feature is also supported by our IDL compiler DICE. The distributor thread would then never block, only accept request and send answers.
2. L4VFS supports a kind of session management (the connection interface): If a task contacts a server for the first time it may ask the server for a new session and use the answer (a thread id) in the following. This can be used for load balancing etc. Currently no server implements this (as far as I know) and the client-side is not active (it is commented out in the source code). You could fix this at: l4vfs/lib/libc_backends/file_table/volumes.c:vol_resolve_thread_for_volume_id(). For your problem this would not yet be sufficient as you need several sessions per task, that is, you need one per local thread of your client. This means you would have to extend this L4VFS mechanism to setup a new connection for each local thread, store this information locally, and use it for each remote function call. I would start with vol_resolve_thread_for_volume_id() and its equivalent from the socket_io-backend.
I personally would prefer to use the first attempt as I think it is more future-proof and maybe elegant, because the exposure of server internal thread structures is not the future.
Regards, Martin
l4-hackers@os.inf.tu-dresden.de