> > 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 si=
> ngle thread can support multiple views into the same buffer - indeed you ca=
> n easily make an editor based on Fl_Text_Buffer and Fl_Text_Editor that mai=
> ntains 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 no=
> t sure how safe the Fl_Text_Buffer implementation is if used like that, tho=
> ugh I have actually done it...)
> Creating a multi-threaded tool to do this may be a lot of work, so you'd re=
> ally 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 separ=
> ate threads?
> As a general rule, callbacks need to run in the context of the main() threa=
> d, and they really want to return as soon as possible.
> If you want to perform some long lived action, triggered by a callback, the=
> n 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 immediatel=
> y, 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 work=
> er thread any time you have changed something that you want the main thread=
>  to display.
> 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 "gi=
> ve 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. Al=
> ways 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 probabl=
> y need to spend a little time getting more familiar with how threads work a=
> nd how to make multi-threaded programs, as that foundation will make your p=
> roject much more robust. Multi-threading is complicated to do well with cur=
> rent C/C++ tools, and very easy to get wrong (in confusing and herd-to-debu=
> g 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 threadin=
> g. What is your background in multi-threading? We can maybe build up from t=
> here?
> Selex ES Ltd
> Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS=
> 14 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.
> ********************************************************************
Thanks again for useful answer. Yea I just misunderstood the meaning of 
FL::awake function,sorry. My background in multithreading is not bad i guess, 
(C++ boost library threads, pthreads,C# threads, Java threads,OpenMp, MPI), but 
I am very new to FLTK, so it's hard for me to combine multithreading and FLTK 
mechanisms  so far. But,you know, your answers were really informative and now 
I understand the problem and possible solutions better. I know that 
multithreading is hard as hell in most times, but I think I'll get through. 
Thanks again, maybe some more questions will arrive later.
fltk mailing list

Reply via email to