Re^5: Annoying threads share problem!

Thanks, but this is also something I've been doing more or less, but this solution is just making the problem halfsolved so to speak. I mean, the

$mw->after(1000);
[download]

is there just to make time for the

&work()
[download]

thread to finnish it's job, so the

$full_PathMatchEntry->configure(-choices => \@choices);
[download]

will actually change something! This is all nice, but its still not the

&work()
[download]

that changes the

$full_PathMatchEntry .
[download]

Maybe this isnt possible as it is now, although I bet there is...
If we break it down to the main problem, this workaround has to be done since the

$full_PathMatchEntry
[download]

can't be shared. Now, how about sharing

@choices ?
[download]

This would all be good, if we didnt had to do:

$full_pathMatchEntry->show_listbox();
[download]

I mean, here we still need to somehow notify the widget that something has changed (thing is that the change to the @choices can happen, and if we don't type anything more, then we won't resisplay the listbox), but how to do that? We can't have a listener in the Tk thread, since then we can't type anything...

Comment on Re^5: Annoying threads share problem! Select or Download Code

Replies are listed 'Best First'.
Re^6: Annoying threads share problem! by zentara (Cardinal) on Oct 10, 2005 at 09:11 UTC
It's possible to do, but I'm not entirely sure what kind of code you are after? From your description of the problem, I'm guessing you want the @choices available at the listbox to change in main, when the thread adds another element to @choices? If so, make @choices shared, and run a timer in main, which saves the old @choices and compares it to the current @choices, and updates the listbox when it detects a difference. Alternatively, you could setup a few extra shared variables, one a flag, and one the new entry. When the thread wants to add a new entry to @choices, it sets the flag, and the new data to add. Pretty much, either way, you are going to need a timer running in the main Tk thread to periodically check for changes. Tk will not watch across thread boundaries for variable changes, you have to actively read them. Another idea, is setup some sort of binding on the listbox, that updates it's selections from @choices, everytime it comes into focus, or when the drop-down-selection list is triggered. I'm not really a human, but I play one on earth. flash japh	[reply]
Re^7: Annoying threads share problem! by Ace128 (Hermit) on Oct 10, 2005 at 12:25 UTC
Yea, this is the current solution. I have some flag that the main (tk) thread checks every 20 ms or so... updates @choices when flag set.. Although I would prefer that the searchUpdate thread notified the main thread somehow, this works just fine. But seems like such a CPU waste (although its not many instructions... some jump and a check and jump back).	[reply]
Re^8: Annoying threads share problem! by zentara (Cardinal) on Oct 10, 2005 at 17:31 UTC
I havn't messed with it lately, and didn't experiment across threads with it, but you might be looking for using shared memory. See "perldoc perlfunc /shmget" and "perldoc perlipc /SysV" . What it does is setup memory segments which can be directly read by separate processes. It requires handling alot of details, but it is supposedly the fastest IPC. Check out Tk-shared-mem-ipc for how to use it it with Tk. I'm not really a human, but I play one on earth. flash japh	[reply]
Re^9: Annoying threads share problem! by Ace128 (Hermit) on Oct 10, 2005 at 19:19 UTC