On Sat, 17 May 2008 02:34:25 +0400 Fedor Gusev [EMAIL PROTECTED] babbled:
Hello.
I'm a Google Summer of Code student working on improving EFM and I
would like to share some thoughts, which my mentor (Nick Hughart) and
I have been discussing.
The thoughts are focused on dealing with slave process. Here goes...
== Slave process ==
There are two considerations on this:
* We want to be able to run several file operations (like copy, move,
etc.) at the same time,
* We want to be able to send a progress report and receive abort
commands in the middle of operation.
In order to achieve this, the following strategy seems reasonable. For
every operation, forced by user, a new slave process will be created.
is this really the right idea? or just have the current slave process schedule
itself a bit better? or have the current slave process spawn its own children
to do the operations (i did consider at some point just running cp -parv or
mv -v etc. etc. and reading stdout for status..).
Inside this process, an idler will scan through the directory tree and
* find out how much work is there to do (for progress reports) and
* queue files for a work idler, which will perform the actual
* operation.
After all queued files are worked out, the process will finish itself.
sure - i would just make a child of the e_fm process do this work - talk back
to e_fm process via stdout. e_fm proc just ipc's collect3ed status back to e.
This work idler will do copies and other operations by small chunks,
so IPC messages are able to be sent and received in the middle of
operation.
We will need one process running always for HAL.
There are some thing more think throught:
* File locking
How to deal with situation, when files in operation are modified
(deleted, moved, etc.)?
ignore it. unix as such has co-operative locking semantics. no need to try and
do what unix doesn't do. not in efm at this stage :)
* Handling errors
What to do with files, when an error occurres? Should everything
just go back or should the process just stop? How to make operations
atomic?
good q. generally speaking you'd paus an operation (eg a recursive delete or a
recursive move or copy) and then allow a ignore this error, ignore all errors
for this op or cancel this now which unrolls any partially done ops (like a
partially copied file) and stops the whole op.
* History system
How to keep track of what was done? How to pass this info from slave
process to the core? What do do here with errors and abortions?
as above. every action is an operation (a 'cp -r', a 'mv' a 'rm -rf' etc.).
these ops each can be partly completed and if so the above holds. the ui needs
to track these ops and get status on them and be able to cancel them at any
point and display current progress.
* Abortions
What to do when a user forces an abortion? What does this actually
mean?
unroll any partially done file copy, but otherwise leave tree of files
copied/moved/deleted as-is. in the future a rollback to beginning of opration
might be nice too - if possible. :)
I'd love to know what other people are thinking on the above. If
you're against something, please, say. Any ideas how to do these
things will be greatfully appreciated. Even your expectations (from
user's point of view) on how these should work are welcome.
Thanks in advance,
Fedor Gusev.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
- Codito, ergo sum - I code, therefore I am --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
