From: Stephen W. <st...@ke...> - 2001-10-24 06:15:43
|
Now at <URL:http://www.kerofin.demon.co.uk/rox/patch.html> is a patch to enable the large file (>2GB) support for Solaris 7 and 8. It should have no effect on non-Solaris systems, but I haven't been able to test it yet. -- Stephen Watson <URL:http://www.kerofin.demon.co.uk/> Glorantha & RISC OS "An eyeful of the future and a bellyful of the past, How beautiful the present when you know it cannae last" |
From: Robin R. <rower@MovieEditor.com> - 2001-10-26 05:53:15
|
Has anyone attempted a Win2k port of ROX-filer? Second question, what is the thinking behind this function in action.c: /* Create two pipes, fork() a child and return a pointer to a GUIside struct * (NULL on failure). The child calls func(). * * If autoq then automatically selects 'Quiet'. */ static GUIside *start_action(gpointer data, ActionChild *func, gboolean autoq) { ... } Why is it forking here? Thanks! Robin |
From: Stephen W. <wa...@ul...> - 2001-10-26 07:47:35
|
In message <004501c15de3$af90db30$0201a8c0@rowboat> "Robin Rowe" <rower@MovieEditor.com> scribbled: > Second question, what is the thinking behind this function in action.c: > > /* Create two pipes, fork() a child and return a pointer to a GUIside struct > * (NULL on failure). The child calls func(). > * > * If autoq then automatically selects 'Quiet'. > */ > static GUIside *start_action(gpointer data, ActionChild *func, gboolean > autoq) > { ... > } > > Why is it forking here? I guess because it is the easiest way of running the action in a seperate thread leaving the filer free to respond to the user. It would be more efficient (if a lot more coding) to use gthreads, but even 2 copies of the filer don't use up much resources. -- Stephen Watson Physicist Ultra Electronics Ltd - Signature Management Systems (UESMS) Tel: +44 (0)1543 878888 (switchboard) Fax: +44 (0)1543 878249 Email: wa...@ul... |
From: Robin R. <rower@MovieEditor.com> - 2001-10-26 21:35:16
|
Thanks for the quick reply. What actions are we forking to? What happens here relative to the user? Cheers, Robin ----- Original Message ----- > In message <004501c15de3$af90db30$0201a8c0@rowboat> > "Robin Rowe" <rower@MovieEditor.com> scribbled: > > > Second question, what is the thinking behind this function in action.c: > > > > /* Create two pipes, fork() a child and return a pointer to a GUIside struct > > * (NULL on failure). The child calls func(). > > * > > * If autoq then automatically selects 'Quiet'. > > */ > > static GUIside *start_action(gpointer data, ActionChild *func, gboolean > > autoq) > > { ... > > } > > > > Why is it forking here? > > I guess because it is the easiest way of running the action in a seperate > thread leaving the filer free to respond to the user. It would be more > efficient (if a lot more coding) to use gthreads, but even 2 copies of the > filer don't use up much resources. > > -- > Stephen Watson Physicist > Ultra Electronics Ltd - Signature Management Systems (UESMS) > Tel: +44 (0)1543 878888 (switchboard) Fax: +44 (0)1543 878249 > Email: wa...@ul... > |
From: Stephen W. <st...@ke...> - 2001-10-27 09:16:08
|
In that finely crafted message <001a01c15e67$3f7ddc60$0201a8c0@rowboat> "Robin Rowe" <rower@MovieEditor.com> wrote: > Thanks for the quick reply. What actions are we forking to? What happens > here relative to the user? Actions like Copy, Move, Disk Usage. -- Stephen Watson <URL:http://www.kerofin.demon.co.uk/> Glorantha & RISC OS "He smiled, and his eyes lied I was staring at a suit with no soul." |
From: Thomas L. <ta...@ec...> - 2001-11-02 16:19:27
|
On Fri, Oct 26, 2001 at 08:46:25AM +0100, Stephen Watson wrote: > In message <004501c15de3$af90db30$0201a8c0@rowboat> > "Robin Rowe" <rower@MovieEditor.com> scribbled: > > > Second question, what is the thinking behind this function in action.c: > > > > /* Create two pipes, fork() a child and return a pointer to a GUIside struct > > * (NULL on failure). The child calls func(). > > * > > * If autoq then automatically selects 'Quiet'. > > */ > > static GUIside *start_action(gpointer data, ActionChild *func, gboolean > > autoq) > > { ... > > } > > > > Why is it forking here? > > I guess because it is the easiest way of running the action in a seperate > thread leaving the filer free to respond to the user. It would be more > efficient (if a lot more coding) to use gthreads, but even 2 copies of the > filer don't use up much resources. Just a couple of points about that: - Using threads means using the thread-safe glib functions instead of the normal ones. These do locking, and therefore slow the whole program down (probably costing more time than multi-threading saves). - The "2 copies" of the filer share all their memory until one copy actually changes a page; then that page (only) is copied. Threading is only really useful when you want the threads to share memory. Passing data by sharing memory is much faster than sending it down a pipe. But since we're only sending text messages, it shouldn't matter (displaying the text messages is the bottleneck). In fact, we want to do the opposite of sharing data: when we fork, the action window should operate on the files that *were* selected, even if we change the selection during the operation. With threading, we'd have to make a copy of the selected files first, but with forking the kernel only does the copy when needed (ie, if the selection actually changes). Not that speed is really an issue in any of this, I just provide the above for interest's sake ;-) -- Thomas Leonard http://rox.sourceforge.net ta...@ec... ta...@us... |
From: Stephen W. <wa...@ul...> - 2001-10-31 12:01:14
|
In message <713...@ke...> Stephen Watson <st...@ke...> scribbled: > Now at <URL:http://www.kerofin.demon.co.uk/rox/patch.html> is a patch to > enable the large file (>2GB) support for Solaris 7 and 8. It should have > no effect on non-Solaris systems, but I haven't been able to test it yet. One bug I've just found is what happens when libvfs doesn't have the large file support (they can't agree on the size and shape of struct stat). I'm putting together a revised patch that disables libvfs entirely when large file support is on. Again, this should only affect Solaris systems. What is the advantage of using mc_stat() over stat()? Is it just the VFS support? -- Stephen Watson Physicist Ultra Electronics Ltd - Signature Management Systems (UESMS) Tel: +44 (0)1543 878888 (switchboard) Fax: +44 (0)1543 878249 Email: wa...@ul... |
From: Thomas L. <ta...@ec...> - 2001-11-02 16:20:57
|
On Wed, Oct 31, 2001 at 11:58:38AM +0000, Stephen Watson wrote: > In message <713...@ke...> > Stephen Watson <st...@ke...> scribbled: > > > Now at <URL:http://www.kerofin.demon.co.uk/rox/patch.html> is a patch to > > enable the large file (>2GB) support for Solaris 7 and 8. It should have > > no effect on non-Solaris systems, but I haven't been able to test it yet. > > One bug I've just found is what happens when libvfs doesn't have the large > file support (they can't agree on the size and shape of struct stat). I'm > putting together a revised patch that disables libvfs entirely when large > file support is on. Again, this should only affect Solaris systems. > > What is the advantage of using mc_stat() over stat()? Is it just the VFS > support? Yep. Does Solaris support avfs? I'd like to drop vfs support at some point (especially as it doesn't work with recent versions of mc anyway)... -- Thomas Leonard http://rox.sourceforge.net ta...@ec... ta...@us... |
From: Stephen W. <st...@ke...> - 2001-11-03 07:15:56
|
In that finely crafted message <200...@ev...> Thomas Leonard <ta...@ec...> wrote: > On Wed, Oct 31, 2001 at 11:58:38AM +0000, Stephen Watson wrote: > > What is the advantage of using mc_stat() over stat()? Is it just the VFS > > support? > > Yep. Does Solaris support avfs? I'd like to drop vfs support at some point > (especially as it doesn't work with recent versions of mc anyway)... Yes, except for suid binaries (it uses LD_PRELOAD). -- Stephen Watson <URL:http://www.kerofin.demon.co.uk/> Glorantha & RISC OS "A man may risk his life for many things: his country, his principles, a tear on the face of a child. Personnaly I'd do it for a ton of cash, an amusing clock and a sack of french porn" - Blackadder III |
From: Thomas L. <ta...@ec...> - 2001-12-06 13:13:26
|
On Tue, Oct 23, 2001 at 06:16:41PM +0100, Stephen Watson wrote: > Now at <URL:http://www.kerofin.demon.co.uk/rox/patch.html> is a patch to > enable the large file (>2GB) support for Solaris 7 and 8. It should have no > effect on non-Solaris systems, but I haven't been able to test it yet. Applied. It seems to be supported on Linux too... Thanks, -- Thomas Leonard http://rox.sourceforge.net ta...@ec... ta...@us... |