User-Agent: Mozilla/5.0 (BeOS; U; BeOS BePC; en-US; rv:1.8b2) Gecko/20050221 Firefox/1.0+ Build Identifier: In bthreads all locking primitives calls to release_sem also reschedules the thread, which may be unwanted in Mozilla. Reproducible: Always Steps to Reproduce:

From the Bebook: Normally, releasing a semaphore automatically invokes the kernel's scheduler. In other words, when your thread calls release_sem(), you're pretty much guaranteed that some other thread will be switched in immediately afterwards, even if your thread hasn't gotten its fair share of CPU time. If you want to subvert this automatism, call release_sem_etc() with a flags value of B_DO_NOT_RESCHEDULE. Preventing the automatic rescheduling is particularly useful if you're releasing a number of different semaphores all in a row: By avoiding the rescheduling you can prevent some unnecessary context switching.

Comment on attachment 175195 [details] [diff] [review] Use the B_DO_NOT_RESCHEDULE flag. r=sergei_d Looks reasonable to avoid switching overhead

Comment on attachment 175195 [details] [diff] [review] Use the B_DO_NOT_RESCHEDULE flag. I agree this seems like a good change to improve performance.

I need someone to check this in.

Patch checked in on the NSPR trunk (NSPR 4.6) and NSPRPUB_PRE_4_2_CLIENT_BRANCH (Mozilla 1.8 Beta 2).

Tqh, after more intensive testing i got feeling that with the patch BeZilla gone less "multitasking". E.g. if you have some page loading in background, it goes harder to open next tab with Alt+T or scroll current page or type text in URL bar. But i don't know how to do objective testing:(

Yes, it is less 'multitasking' because that's what this patch does. It allows a thread to continue running more of the time-slice it's supposed to run instead of giving much of it away because it released a semaphore. This means less switching between threads, but also less wasted time on switching. It should reduce cpu-load on processing intensive tasks (loading, downloading, parsing), but quick tasks (like UI usually is) will get a minor setback. Startup is faster, cvar and cvar2 (use a cmdline flag to see timing) in nspr tests are faster. (Do 'make cvar cvar2' in there and make a symbolic link lib to dist/lib to run). The snappiness will probably be better when we set our rendering proxy thread (for all the BWindow threads) to be of B_DISPLAY_PRIORITY as it should. It's one of the patches I will work on once our native app patches gets commited. You can try doing that today in nsAppshell Spinup or Run.