Date: Thu, 8 Apr 1999 23:28:38 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: reg@shale.csir.co.za (Jeremy Lea) Cc: patl@phoenix.volant.org, freebsd-mozilla@FreeBSD.ORG Subject: Re: current state of the mozilla project on freebsd... (port) Message-ID: <199904082328.QAA02792@usr08.primenet.com> In-Reply-To: <19990408105937.M1798@shale.csir.co.za> from "Jeremy Lea" at Apr 8, 99 10:59:37 am
next in thread | previous in thread | raw e-mail | index | archive | help
> There is going to be a Milestone 4 release in the next day or two, and > that runs quite well on FreeBSD. I'll see if I can get the port > updated. I've asked for separate source tarballs for their runtime code > (NSPR) and the browser, since they have to be built separately, and I > want to make two ports... Otherwise I'll have to make two ports using > the same source tarball. Great! > FreeBSD projects: > *URGENT* The library (XPTCall) which allows Javascript to call their > cross-platform implementation of COM (XPCOM) uses some hand coded > assembly to handle vtable conversion of objects. This does not work > on FreeBSD, since there is no one to write the code... > http://www.mozilla.org/scriptable/xptcall-faq.html. I suspect it > would be very similar to the existing Linux code, and it's only > about 300 lines including the licence and comments... IMO, the same code issues here are the code issues with the gcc 2.8.1 exceptions patch that I sent to obrian@freebsd.org, and that was included in the (so far) ill-fated switch to the threads-unfriendly EGCS. If you fix this for Mozilla, I believe you'll have the stack unwinding information to make gcc 2.8.1 (and EGCS, such as it is) work without resorting to longjmp. > *NEEDED* The cross platform portability layer (NSPR) works for their > threading, but needs some testing for our threads (libc_r) and for > Richard's Linux threads port. There are also a few places where I > think they are doing some things wrong - mostly with select() and > poll() because some functions seem very slow. I'm pretty sure that there us a pretty serious problem with threading on systems where the threading is not serially non-preemptive. This basically means that the threaded code implementation works on Solaris, Linux, and WIN32, but fails on FreeBSD, Macintosh, and other platforms that use non-kernel threads and/or enable the cooperative user space scheduling components, if they exist on the OS. This is really a "run to completion issue"; the way it is resolved on these other OS's is that the thread runs to completion. The behaviour on the Mac and FreeBSD and other systems is that, instead of selecting the thread that was running before an involuntary context switch, come the next time slice, any ready-to-run thread is selected, and execution starts. This is most easily apparent in a JavaScript UI that uses multiple image maps with popup menus, tooltips, or static forms with JavaScript OnSubmit. The visible effect is that if you allow the images to fully download before moving the mouse (if you have motion based scripts, such as tooltips) or clicking on anything (otherwise), then the interface works; but if you don't, then the interface fails. It's possible to modify an interface (as I have discovered) to effectively serialize the image downloads. This is either a problem in thread-safety of the GIF decoder (note: IE is significantly faster, as they implement the GIF unpacking using a native implementation class), or a problem with thread resource/context locking that's missing. I'd really like to address the FreeBSD threading architecture at some time. > *NICE TO HELP* Mozilla currently has no crypto code, since they can't > work on it without getting their wrists slapped (they even had to > remove the MD5 code...). It would be nice if some FreeBSD people > could help out. Can they commit this? The person to contact is probably Mark Murray; he probably won't be able to do the work himself, but he knows what an abstract exportable framework looks like, and he might have a pointer to someone else in South Africa who would be willing to bring the thing up to compliance with the internationally distributed FreeBSD interfaces (FreeBSD crypto work goes on offshore to avoid ITAR issues). > For those people who have not been following mozilla.org, they have > completely dumped the old code base (used up to 4.x) and re-implemented > the package in a really innovative way. Everything is based around > their new layout engine (known as Gecko), which is a small, fast and > standards compliant (any behaviour outside of the W3C standards is > considered a bug). I have a small bug to report. The Gecko code, in a form that is refreshed and which contains radio buttons in a table puts the tab stop selection area to the right of the radio button instead of on the radio button itself. I can provide a copy of a form where this happens, if necessary (observed on the WIN32 version, since the FreeBSD, Mac, and Linux version are currently useless for JavaScript interface testing: the FreeBSD and Mac for the threading issues, above, and the Linux for Linux specific problems that I didn't bother to investigate fully). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mozilla" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904082328.QAA02792>