Multiprocessing based implementation will likely be quite hard, and once
you walk the trees anyway and copy the data over the process boundary, it
could cause bad pauses in execution.

I have often thought how nice it would be to have "flat" storage for the
leo document, so that you could just copy over a flat chunk of memory and
let other processes traverse that. Doing that is a somewhat nontrivial
undertaking, to say the least :).

I'd just start with threads, despite the GIL problems.



On Sun, Mar 10, 2013 at 5:28 PM, Terry Brown <[email protected]>wrote:

> On Sun, 10 Mar 2013 08:13:41 +0200
> "Ville M. Vainio" <[email protected]> wrote:
>
> > I'm pretty sure saving is cpu bound; for "normal" size documents,
> flushing
> > that kind of stuff to disk (or memory buffers that are to be written to
> > disk) shouldn't take significant amount of time.
>
> Probably right, so could you use `multiprocessing` instead of
> `threading`?  More challenging implementation wise, but I'm wondering
> if it's even possible, in terms of handing over the in-memory data
> structure?
>
> Cheers -Terry
>
> > On Sat, Mar 9, 2013 at 10:46 PM, Terry Brown <[email protected]
> >wrote:
> >
> > > I guess this is a wishlist item - I suspect it's a result of my
> > > workflow that might be quite different from other peoples, but I often
> > > need to save 4, 6, even more open changed Leo files at once.  Mainly
> > > when I'm filing / adjusting todo items, although at the end of a
> > > session having 4 changed files open can't be that unlikely.
> > >
> > > So it would be really nice if c.saveAll() could be threaded.  Even as I
> > > write this, it gets more complicated as I think about it :-}
> > >
> > >   - each thread should do no user interface calls, or at least no calls
> > >     that aren't deferred to the main thread
> > >
> > >     - that's ok, would take quite a bit of tracing to catch them all,
> > >       but doable - except - plugins called from save hooks might break
> > >       the rule
> > >
> > >   - updating recent files list would have to be done properly, not a
> > >     big deal
> > >
> > >   - multiple threads saving to the same external files would be a
> > >     problem, that's the complication that only just occurred to me
> > >
> > > I don't typically have the same external file referenced from multiple
> > > Leo files, why would you do that... so the last problem, although
> > > potentially major, might be theoretical more than practical.
> > >
> > > Hmm, well it's a thought.  First thing to check, is saving IO bound or
> > > CPU bound...
> > >
> > > Cheers -Terry
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> Groups
> > > "leo-editor" group.
> > > To unsubscribe from this group and stop receiving emails from it, send
> an
> > > email to [email protected].
> > > To post to this group, send email to [email protected].
> > > Visit this group at http://groups.google.com/group/leo-editor?hl=en.
> > > For more options, visit https://groups.google.com/groups/opt_out.
> > >
> > >
> > >
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "leo-editor" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/leo-editor?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/leo-editor?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to