MacArthur, Ian (Selex ES, UK)
2013-04-16 14:07:59 UTC
First of all, let me describe my task to make it
easier for you to understand what I need. I am trying to make a
multithreaded text editor.
To what end? In most cases, manipulation of text is "easy enough" that a single thread can support multiple views into the same buffer - indeed you can easily make an editor based on Fl_Text_Buffer and Fl_Text_Editor that maintains multiple views into the same text buffer in separate windows.easier for you to understand what I need. I am trying to make a
multithreaded text editor.
Though whether it is a good idea to do that or not I'm not sure...! (I'm not sure how safe the Fl_Text_Buffer implementation is if used like that, though I have actually done it...)
Creating a multi-threaded tool to do this may be a lot of work, so you'd really need to be sure you needed it!
Firstly I thought to make full process of
redrawing of each window of the editor multi threaded, but as I
understood from your arguments it's impossible because of graphics card
restrictions.
Not impossible. But tricky to do safely and robustly.redrawing of each window of the editor multi threaded, but as I
understood from your arguments it's impossible because of graphics card
restrictions.
Threads can be quite "difficult"...
So my aim now is to make functionality of this windows
multithreaded. All process of work with text editor is based on work
with text buffer ( which in my design is unique for each window) and
reacting on buttons callbacks like copy, open,etc. So, now my questions
1) Is it possible to make callback functions multithreaded? Maybe you
can give some example?
Not sure what you are asking here.multithreaded. All process of work with text editor is based on work
with text buffer ( which in my design is unique for each window) and
reacting on buttons callbacks like copy, open,etc. So, now my questions
1) Is it possible to make callback functions multithreaded? Maybe you
can give some example?
Are you asking about putting the functionality of the callbacks, into separate threads?
As a general rule, callbacks need to run in the context of the main() thread, and they really want to return as soon as possible.
If you want to perform some long lived action, triggered by a callback, then it is best *not* to perform that action in the context of the callback at all. You can have the callback spawn a worker thread and return immediately, then reap the results of that worker thread at some later time, e.g. via an Fl::awake() call or a timer or some such...
Is that what you mean?
2) The "lags"(long-term operations) in my program are unexpected by
design so I don't know in which place to make FL::awake() to give
control back to main thread.
Um, that's not really the way it works. You call Fl::awake() from your worker thread any time you have changed something that you want the main thread to display.design so I don't know in which place to make FL::awake() to give
control back to main thread.
You do not give control "back to the main thread", since all threads run at the same time, in parallel.
So I guess I need to combine multi
threading with timer callbacks mechanism. Like "if window not
responding for 2 sec, give control to another thread, while operation
is still in progress".
Again, that's not really the way it works - all the threads run at the same time, you don't really choose which runs when, so there is no scope to "give control to another thread" per se.threading with timer callbacks mechanism. Like "if window not
responding for 2 sec, give control to another thread, while operation
is still in progress".
The main idea is that you work in one window
while some operation continues in another one. What are your
ideas/experience about these? Maybe some example? So far, if i do some
long-time loop in one of the window's callback function another just
stops as well.
Never do long operation in a callback, as that will stall the fltk loop. Always do long operations outside the fltk context (e.g. in a worker thread) or contrive for your long operation to call Fl::check() quite often...while some operation continues in another one. What are your
ideas/experience about these? Maybe some example? So far, if i do some
long-time loop in one of the window's callback function another just
stops as well.
3)How can I pass control back to child's thread from main thread? For
example I made fl::awake() during some long-term operation,because user
started input in other window but i need that operation to be done till
end, so when user stopped input i want main thread to "return" to that
position in child's thread where it was left.
It sounds like you have misunderstood what Fl::awake() does...example I made fl::awake() during some long-term operation,because user
started input in other window but i need that operation to be done till
end, so when user stopped input i want main thread to "return" to that
position in child's thread where it was left.
P.S. I I know that most of this things can be done ( and possibly
easier) single threaded , but multiple threads is a must for this
project. Thanks for your fast and informative response.
I'm not sure how much experience you have of using threads, but it does not sound like you are that familiar with the techniques involved. You probably need to spend a little time getting more familiar with how threads work and how to make multi-threaded programs, as that foundation will make your project much more robust. Multi-threading is complicated to do well with current C/C++ tools, and very easy to get wrong (in confusing and herd-to-debug ways!)easier) single threaded , but multiple threads is a must for this
project. Thanks for your fast and informative response.
I'm not sure how to describe to you, how to make these things work, as I'm not sure how much understanding you have of the issues surrounding threading. What is your background in multi-threading? We can maybe build up from there?
Selex ES Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************