CamelBones

On Wed, 3 Nov 2010, Matt Sergeant wrote:

> I can't seem to join() threads under camelbones.
>
> You can see a simple example:
>
> create an app.
>
> Add this before $nsApp->run:
>
> use threads;
> my $thread = threads->create(sub { return 1 });
> #my $val = $thread->join();
>
> If you uncomment the ->join line it crashes for me.

So I've tried a different way of doing this, using fork, and using 
NSThread. None work...

fork basically says that I can't do anything in the main process any more 
unless I exec.

NSThread just completely crashes. I can't get it to work at all.

So is there some other way I can get the GUI to update while I'm doing 
other stuff? I'm basically scanning a directory and adding files to 
DRFile/DRFolder objects.

What I *could* do is simply setup a ticker and add a file/directory with 
every tick. But that seems a bit limiting in how fast it can go... I guess 
maybe this would work:

Setup ticker with granularity N milliseconds:
   Every tick, pull in as many files until N-10 milliseconds has passed
   Setup a ticker to fire in 10 milliseconds to do it again
Repeat until all files are done

Thoughts?

Or maybe we can get threads working right :)

I've had very little luck with Perl threading in general, independent
of CamelBones. DBI warns against using threads too. The impression I
get is that it's a low priority among the core devs.

CamelBones could certainly handle threads better as well - I've taken
a cue from the core devs, and haven't put much effort into it. There's
a superficial level of threading support, in that if a multi-threaded
Perl is detected, the framework will "use threads" as soon as the Perl
interpreter is initialized, and makes sure to put Cocoa into its
multi-threaded mode. There are probably bugs in how Perl's context
pointers are handled though - trying to figure out what all those
nested macros expand to makes my head hurt.

On Thu, Nov 4, 2010 at 9:51 AM, Matt Sergeant <matt@...> wrote:
>
> So is there some other way I can get the GUI to update while I'm doing
> other stuff? I'm basically scanning a directory and adding files to
> DRFile/DRFolder objects.
>
> What I *could* do is simply setup a ticker and add a file/directory with
> every tick. But that seems a bit limiting in how fast it can go...

Not *that* limiting though. After adding each file, you could simply
issue a -performSelector:withObject:afterDelay: with a delay of zero.
That would introduce the overhead of pumping the main event loop once
after each file, but doing so would in turn allow the user to easily
cancel the operation.

Also, is what you're doing really *that* slow? I've been writing code
for ShuX to add support for browsing docs in the .par bundles that
ship with CamelBones. I'm using File::Find to scan both core & CPAN
directories, Archive::Zip to get the directory listing from all of the
.par bundles, *and* filtering both to choose only the relevant files,
and even doing all of that I still don't get a spinning beachball.
Note that all of that work is done in pure Perl though - I'm not
working with any Cocoa objects in File::Find's "wanted" function, for
instance, since crossing the language bridge is an expensive operation
in comparison to calling a Perl method.

sherm--

-- 
Cocoa programming in Perl:
http://camelbones.sourceforge.net

On Thu, 4 Nov 2010, Sherm Pendley wrote:

>> What I *could* do is simply setup a ticker and add a file/directory with
>> every tick. But that seems a bit limiting in how fast it can go...
>
> Not *that* limiting though. After adding each file, you could simply
> issue a -performSelector:withObject:afterDelay: with a delay of zero.
> That would introduce the overhead of pumping the main event loop once
> after each file, but doing so would in turn allow the user to easily
> cancel the operation.

OK, that sounds doable if it allows the GUI run loop to kick in.

> Also, is what you're doing really *that* slow? I've been writing code
> for ShuX to add support for browsing docs in the .par bundles that
> ship with CamelBones. I'm using File::Find to scan both core & CPAN
> directories, Archive::Zip to get the directory listing from all of the
> .par bundles, *and* filtering both to choose only the relevant files,
> and even doing all of that I still don't get a spinning beachball.
> Note that all of that work is done in pure Perl though - I'm not
> working with any Cocoa objects in File::Find's "wanted" function, for
> instance, since crossing the language bridge is an expensive operation
> in comparison to calling a Perl method.

Yep, it's constructing the DRFile/Folder structure that's slow, not the 
wanted() stuff... Though even that can be slow with tens of thousands of 
files.

Time for a bit of a re-write :-)

Though really we should consider ways to solve this threading support 
issue as it's the recommended Cocoa way of keeping the GUI active.


Matt.