> 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.
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.
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
> are:
> 1) Is it possible to make callback functions multithreaded? Maybe you
> can give some example?

Not sure what you are asking here.
Are you asking about putting the functionality of the callbacks, into separate 

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 
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.

> 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...

> 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...

> 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!)

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 
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.

fltk mailing list

Reply via email to