Re: A question on discardEventsMatchingMask:beforeEvent:
Hallo Richard, Am Fri, 28 Jan 2011 15:33:57 + schrieb Richard Frith-Macdonald : > When I was looking at it, I found it hard to see how best to make a fast > allocation/deallocation scheme thread-safe. I learned this from ptmalloc3. The comment explaining the central idea is this: /* arena_get() acquires an arena and locks the corresponding mutex. * First, try the one last locked successfully by this thread. (This * is the common case and handled with a macro for speed.) Then, loop * once over the circularly linked list of arenas. If no arena is * readily available, create a new one. In this latter case, `size' * is just a hint as to how much memory will be required immediately * in the new arena. */ Of course, when you need to free(), you have to get the arena you allocated from. But you usually do not have to contend with two dozen threads who want to use the same arena. In fact, lock conflicts are extremely rare with this scheme. (Oh, searching the arena list for a free arena needs to be locked against creating a new arena. But remember that you usually can just use the same arena as last time, especially if you do lots of allocations. Also, you need a very short lock for marking the arena busy. Or just look at how ptmalloc3 does it!) This stuff is FAST. Mit freundlichen Grüßen aus Münster / with kind regards - Kai Henningsen -- SPUeNTRUP Software An der Kleimannbrücke 52 D-48157 Münster, Germany Reg:Münster Nr.29047 Fon:+49 700 CALL CATS (=22552287) Fon:+49 251 322 311 0 Fax:+49 251 322 311 99 Web:http://www.cats.ms Mail: support-k...@cats.ms ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: A question on discardEventsMatchingMask:beforeEvent:
On 31 Jan 2011, at 09:51, SPUeNTRUP - Kai Henningsen wrote: >> When I was looking at it, I found it hard to see how best to make a fast >> allocation/deallocation scheme thread-safe. > > I learned this from ptmalloc3 ptmalloc() is very heavily optimised for the case in which malloc() and free() are both called in the same thread. For NSEvent, this may well not be the case, as the event is delivered to a run loop, which may pass it off to another thread. Of course, if you want really fast NSEvent allocation and deallocation, then you should take advantage of the fact that NSEvents are inserted at the bottom of the run loop, are immutable, and rarely persist beyond a single run loop iteration. You can then allocate an NSEvent subclass on the stack, inject this, and have its -retain method return a copy of itself on the heap, so you are only calling malloc() at all when someone tries to keep the event beyond the run loop iteration. This would require some tweaking of the current code, I think, because NSEvents are queued by the run loop. Something for Banlu to play with... David -- Send from my Jacquard Loom ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Long pauses in applications maybe due to gpbs : Timed out waiting for X...
The interesting line is: Owning program failed to convert data. Could it be that the content of the pasteboard was something that wasn't a string, but our code always expects that it can be converted to a string? Am 30.01.2011 22:10, schrieb Philippe Roussel: > Le samedi 29 janvier 2011 à 21:26 +0100, Philippe Roussel a écrit : >> Le samedi 29 janvier 2011 à 14:11 +0100, Fred Kiefer a écrit : >>> I remember this behaviour form way back, but cannot remember seeing it >>> in recent years. I may just have been lucky, though. >>> Could you please start gpbs manually and switch on debug output for "Pbs"? >>> This command should do the trick: >>> gpbs --GNU-Debug=Pbs --verbose --verbose >>> >>> Providing verbose twice should given even more output than using in once:-) >>> >>> The whole pasteboard interaction is a bit of a mess. >> >> And, how surprising, I can't reproduce the problem anymore. And I have >> no idea what could have changed since yesterday... > > I managed to capture a 3 second hang but I'm not sure the log will help > much. The first panel I opened worked fine but at 22:05:44 I opened a > second one in the same application hit the timeout : > > 2011-01-30 22:05:24.002 gpbs[7030] get data for > type 'NSStringPboardType' version 1 > 2011-01-30 22:05:24.002 gpbs[7030] PropertyNotify. > 2011-01-30 22:05:24.002 gpbs[7030] Selection (PRIMARY) notify - 'None'. > 2011-01-30 22:05:24.002 gpbs[7030] Owning program failed to convert data. > 2011-01-30 22:05:24.002 gpbs[7030] SelectionNotify. > 2011-01-30 22:05:24.003 gpbs[7030] PropertyNotify. > 2011-01-30 22:05:24.003 gpbs[7030] Selection (PRIMARY) notify - 'None'. > 2011-01-30 22:05:24.003 gpbs[7030] Owning program failed to convert data. > 2011-01-30 22:05:24.003 gpbs[7030] SelectionNotify. > 2011-01-30 22:05:24.003 gpbs[7030] set data for > type 'NSStringPboardType' version 1 > 2011-01-30 22:05:24.003 gpbs[7030] set data for 0x9a0b9c8 > 2011-01-30 22:05:24.003 gpbs[7030] get data for 0x9a0b9c8 > 2011-01-30 22:05:44.903 gpbs[7030] get data for > type 'NSStringPboardType' version 1 > 2011-01-30 22:05:47.906 gpbs[7030] Timed out waiting for X append for > Selection > 2011-01-30 22:05:47.906 gpbs[7030] PropertyNotify. > 2011-01-30 22:05:47.906 gpbs[7030] PropertyNotify. > 2011-01-30 22:05:47.906 gpbs[7030] Selection (PRIMARY) notify - 'None'. > 2011-01-30 22:05:47.906 gpbs[7030] Owning program failed to convert data. > 2011-01-30 22:05:47.907 gpbs[7030] SelectionNotify. > 2011-01-30 22:05:47.907 gpbs[7030] set data for > type 'NSStringPboardType' version 1 > 2011-01-30 22:05:47.907 gpbs[7030] set data for 0x9a0b9c8 > 2011-01-30 22:05:47.907 gpbs[7030] get data for 0x9a0b9c8 > > Hope this helps, > Philippe ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Long pauses in applications maybe due to gpbs : Timed out waiting for X...
On Mon, Jan 31, 2011 at 11:56:45AM +0100, Fred Kiefer wrote: > The interesting line is: > Owning program failed to convert data. > > Could it be that the content of the pasteboard was something that wasn't > a string, but our code always expects that it can be converted to a string? I guess I'll have to trace the execution to answer that. But before that I have to mention that this message appears multiple times in this log and I only had one timeout all this time. Are you sure this is related ? [snip] > > 2011-01-30 22:05:24.002 gpbs[7030] get data > > for type 'NSStringPboardType' version 1 > > 2011-01-30 22:05:24.002 gpbs[7030] PropertyNotify. > > 2011-01-30 22:05:24.002 gpbs[7030] Selection (PRIMARY) notify - 'None'. > > 2011-01-30 22:05:24.002 gpbs[7030] Owning program failed to convert data. > > 2011-01-30 22:05:24.002 gpbs[7030] SelectionNotify. > > 2011-01-30 22:05:24.003 gpbs[7030] PropertyNotify. > > 2011-01-30 22:05:24.003 gpbs[7030] Selection (PRIMARY) notify - 'None'. > > 2011-01-30 22:05:24.003 gpbs[7030] Owning program failed to convert data. > > 2011-01-30 22:05:24.003 gpbs[7030] SelectionNotify. > > 2011-01-30 22:05:24.003 gpbs[7030] set data > > for type 'NSStringPboardType' version 1 > > 2011-01-30 22:05:24.003 gpbs[7030] set data for 0x9a0b9c8 > > 2011-01-30 22:05:24.003 gpbs[7030] get data for 0x9a0b9c8 > > 2011-01-30 22:05:44.903 gpbs[7030] get data > > for type 'NSStringPboardType' version 1 > > 2011-01-30 22:05:47.906 gpbs[7030] Timed out waiting for X append for > > Selection > > 2011-01-30 22:05:47.906 gpbs[7030] PropertyNotify. > > 2011-01-30 22:05:47.906 gpbs[7030] PropertyNotify. > > 2011-01-30 22:05:47.906 gpbs[7030] Selection (PRIMARY) notify - 'None'. > > 2011-01-30 22:05:47.906 gpbs[7030] Owning program failed to convert data. > > 2011-01-30 22:05:47.907 gpbs[7030] SelectionNotify. > > 2011-01-30 22:05:47.907 gpbs[7030] set data > > for type 'NSStringPboardType' version 1 > > 2011-01-30 22:05:47.907 gpbs[7030] set data for 0x9a0b9c8 > > 2011-01-30 22:05:47.907 gpbs[7030] get data for 0x9a0b9c8 -- Sur le plus beau trône du monde, on n'est jamais assis que sur son cul ! Montaigne ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: A question on discardEventsMatchingMask:beforeEvent:
Hallo Herr Chisnall, Hallo Frau Chisnall, Hallo David, Am Mon, 31 Jan 2011 09:59:10 + schrieb David Chisnall : > On 31 Jan 2011, at 09:51, SPUeNTRUP - Kai Henningsen wrote: > > >> When I was looking at it, I found it hard to see how best to make a fast > >> allocation/deallocation scheme thread-safe. > > > > I learned this from ptmalloc3 > > > ptmalloc() is very heavily optimised for the case in which malloc() and > free() are both called in the same thread. For NSEvent, this may well not be > the case, as the event is delivered to a run loop, which may pass it off to > another thread. Actually, I used it in a context where free() on a different thread from malloc() was the rule, not the exception, and it was fine. The other performance problem I had was the central object lock in libobjc - changing that to a per-object lock also helped performance a lot, in a program with many threads. Each of these changes resulted in drastic performance improvements, in both cases by reducing lock contention by a large factor. (I had yet another case with a lock of my own.) The application was nearly unrecognizable afterwards, it was so much faster. Mit freundlichen Grüßen aus Münster / with kind regards - Kai Henningsen -- SPUeNTRUP Software An der Kleimannbrücke 52 D-48157 Münster, Germany Reg:Münster Nr.29047 Fon:+49 700 CALL CATS (=22552287) Fon:+49 251 322 311 0 Fax:+49 251 322 311 99 Web:http://www.cats.ms Mail: support-k...@cats.ms ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Google Summer of Code 2011
The website for the Google Summer of Code (GSoC) is up: http:// www.google-melange.com/ The timeline is here: http://www.google-melange.com/document/show/ gsoc_program/google/gsoc2011/timeline the first important date for our project is February 28 19:00 UTC, when the mentoring organizations can begin submitting applications to Google. cheers, Lars ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep + libicu on Windows
New patch for anyone who wants to try it out. Apparently, on Windows ICU builds and installs 2 different libicudata46.dll libraries. One is a stubdata version with none of the actual needed data, that's why a lot the ICU tests in the testsuites were failing. On top of that, ICU was calling the data library icudata46.dll, so GNUstep linked against the stubdata version. Stef icu4c-4_6-mingw-gnustep.diff Description: Binary data ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
