Jason Tackaberry wrote: > Dirk Meyer wrote: >> Yes. For kaa.vfs (and also kaa.thumb) I was thinking about a process >> and using your IPC. > > Putting kaa.vfs in a separate process makes sense given that there are > database locking issues. But for thumbnail generation, this could > easily happen in another thread. Actually, thumbnail generation is > something the vfs should take care of, so this would be a separate > thread in the vfs process.
Yes. I will change some stuff kaa.thumb to make it use a thread and not in the main loop. I will add it directly into Freevo to test it while kaa.vfs is being created. >> Both are host local and should communicate over an unix socket. I >> have no idea how gconfd or the kde stuff is working, but I think of >> the following: > > My IPC stuff works both on unix sockets and tcp sockets. I've done some > work updating it to work with notifier, but there's some niggles I have > to work through. Can you send it to me? > (For synchronous calls, it calls notifier.step() until it receives > the reply from the remote end, but this causes problems in that the > handle_read() callback could get called when there's nothing on the > wire, so recv() blocks. I'll have to look at using nonblock > sockets.) Yes, you should use non blocking sockets. And notifier.step is exactly what you need to do to wait. > Once I have it working, I could add it to kaa.base. I think it's a > quick and easy way to do IPC. Yes please. > Maybe it doesn't have the features that mbus has, but for something > internal to kaa it would work well and transparently. That's why I want it. It is only internal in the vfs. Mbus is nice for 'open' communication with different processes with a well defined API. > I was thinking about the possibility of the vfs client API doing writes > via IPC, but doing reads in-process. This would avoid IPC overhead for > most cases, but also complicates the design. I had the same idea. >> - When the server is needed, it will auto start. I don't want to start >> the process myself. >> - When there is already a process running, use it without starting >> another >> - A process without clients will exit after x seconds > > If the vfs socket filename is known (and it probably should be, because > the vfs database file will be known -- i.e. if the vfs database is > ~/.freevo/vfs.db then the socket would be ~/.freevo/vfs.socket), Maybe in a /tmp/kaa-<uid> directory. We can check the permissions of that dir to avoid security problems. > this is easy to do. Just connect to the socket, and if the > connection is refused, you know the vfs server isn't running, so the > client API will launch it. Yes and no. If the server is not running and you start two processes (freevo and recordserver), we need to take care that only one process is winning. Dischi -- "error located between ears of user!"
pgpLoKKFcWcxT.pgp
Description: PGP signature
