Re: [AOLSERVER] Good reading: Yahoo moving to PHP
The article mentions that they stayed away from Java because of the thread implementation on FreeBSD (presumably 4.x). Given that AOLserver uses threads heavily, does anyone have experience running it under FreeBSD? Is it OK? OK under load?
Re: [AOLSERVER] Good reading: Yahoo moving to PHP
Peter, I've had a few AOLserver installations under FreeBSD -- one with a fair amount of load. I never had a problem w/ the FreeBSD/AOLserver other than minor compilation issues and runtime configuration issues (discoverd the I had to have nsd prebind). It works great. The threads issue was an odd argument considering that Apache now utilizes threads -- I am assuming they are using Apache with PHP of course.. -Ayan On Wed, 30 Oct 2002, Peter M. Jansson wrote: The article mentions that they stayed away from Java because of the thread implementation on FreeBSD (presumably 4.x). Given that AOLserver uses threads heavily, does anyone have experience running it under FreeBSD? Is it OK? OK under load?
Re: [AOLSERVER] Good reading: Yahoo moving to PHP
In a message dated 10/30/02 9:03:22 AM, [EMAIL PROTECTED] writes: The article mentions that they stayed away from Java because of the thread implementation on FreeBSD (presumably 4.x). Given that AOLserver uses threads heavily, does anyone have experience running it under FreeBSD? Is it OK? OK under load? Hi, I do some of the aolserver development on my FreeBSD laptop but I wouldn't run it there - default threads are user based which perform poorly. You can get AOLserver to link against a port of Linux threads which emulate system clone() based threads with BSD rfork() which may perform better. -Jim
Re: [AOLSERVER] Good reading: Yahoo moving to PHP
Jim, A library threads implementation doesn't necessarily mean poor performance. On a single CPU machine, it can actually be more effecient than a kernel implementation. Although the use of user threads precludes scaling threads across CPUs I think the FreeBSD threads library works well. Not to start a discussion about pthreads implementations, I just wanted to note that library implementations do not inherently perform poorly. -Ayan On Wed, 30 Oct 2002, Jim Davidson wrote: In a message dated 10/30/02 9:03:22 AM, [EMAIL PROTECTED] writes: The article mentions that they stayed away from Java because of the thread implementation on FreeBSD (presumably 4.x). Given that AOLserver uses threads heavily, does anyone have experience running it under FreeBSD? Is it OK? OK under load? Hi, I do some of the aolserver development on my FreeBSD laptop but I wouldn't run it there - default threads are user based which perform poorly. You can get AOLserver to link against a port of Linux threads which emulate system clone() based threads with BSD rfork() which may perform better. -Jim
Re: [AOLSERVER] Good reading: Yahoo moving to PHP
I know there were problems with threads/Java/Linux at one point (not sure if it was fixed). I think that's why there came about this green threads and native threads variants. Not sure if the same limitation is on FreeBSD. I *think* the problem was that it actually wouldn't distribute the threads across multiple CPUs, or something like thatI just faintly remember... --brett On Wed, 2002-10-30 at 06:54, Ayan George wrote: Jim, A library threads implementation doesn't necessarily mean poor performance. On a single CPU machine, it can actually be more effecient than a kernel implementation. Although the use of user threads precludes scaling threads across CPUs I think the FreeBSD threads library works well. Not to start a discussion about pthreads implementations, I just wanted to note that library implementations do not inherently perform poorly. -Ayan On Wed, 30 Oct 2002, Jim Davidson wrote: In a message dated 10/30/02 9:03:22 AM, [EMAIL PROTECTED] writes: The article mentions that they stayed away from Java because of the thread implementation on FreeBSD (presumably 4.x). Given that AOLserver uses threads heavily, does anyone have experience running it under FreeBSD? Is it OK? OK under load? Hi, I do some of the aolserver development on my FreeBSD laptop but I wouldn't run it there - default threads are user based which perform poorly. You can get AOLserver to link against a port of Linux threads which emulate system clone() based threads with BSD rfork() which may perform better. -Jim -- Brett Schwarz brett_schwarz AT yahoo.com
Re: [AOLSERVER] segfault in ns_malloc, _smalloc
Zoran -
Is the bug in clock scan ... -gmt 1 or clock format ... -gmt 1? The code
you posted is a change to the FormatClock function, which isn't used by clock
scan.
Doug
---
Doug Harris [EMAIL PROTECTED]
Zoran Vasiljevic
[EMAIL PROTECTED]To: [EMAIL PROTECTED]
OM cc:
Sent by: AOLserverSubject: Re: [AOLSERVER] segfault in
ns_malloc,
Discussion_smalloc
AOLSERVER@LISTSER
V.AOL.COM
10/29/2002 10:52
AM
Please respond to
AOLserver
Discussion
On Monday 28 October 2002 17:03, you wrote:
Zoran, can you post the changes to the list, please, if they're not too
large?
Here it is. This function is at the end of tcl8.3.X/generic/tclClock.c file.
Just replace the one you find there with the copy below and recompile.
This fixes the clock scan ... -gmt 1 subtle MT-bug on *Solaris* builds.
Linux is afaik not affected. For other platforms: no idea.
When two or more threads try to do the above command, the process env
gets corrupted.
Zoran
cut here
/*
*-
*
* FormatClock --
*
* Formats a time value based on seconds into a human readable
* string.
*
* Results:
* Standard Tcl result.
*
* Side effects:
* None.
*
*-
*/
static int
FormatClock(interp, clockVal, useGMT, format)
Tcl_Interp *interp; /* Current interpreter. */
unsigned long clockVal; /* Time in seconds. */
int useGMT; /* Boolean */
char *format; /* Format string */
{
struct tm *timeDataPtr;
Tcl_DString buffer, uniBuffer;
int bufSize;
char *p;
int result;
time_t tclockVal;
#ifndef HAVE_TM_ZONE
int savedTimeZone = 0; /* lint. */
char *savedTZEnv = NULL;/* lint. */
#endif
#ifdef HAVE_TZSET
/*
* Some systems forgot to call tzset in localtime, make sure its done.
*/
static int calledTzset = 0;
Tcl_MutexLock(clockMutex);
if (!calledTzset) {
tzset();
calledTzset = 1;
}
Tcl_MutexUnlock(clockMutex);
#endif
/*
* If the user gave us -format , just return now
*/
if (*format == '\0') {
return TCL_OK;
}
#ifndef HAVE_TM_ZONE
Tcl_MutexLock(clockMutex);
/*
* This is a kludge for systems not having the timezone string in
* struct tm. No matter what was specified, they use the local
* timezone string.
*/
if (useGMT) {
char *varValue;
varValue = Tcl_GetVar2(interp, env, TZ, TCL_GLOBAL_ONLY);
if (varValue != NULL) {
savedTZEnv = strcpy(ckalloc(strlen(varValue) + 1), varValue);
} else {
savedTZEnv = NULL;
}
Tcl_SetVar2(interp, env, TZ, GMT, TCL_GLOBAL_ONLY);
savedTimeZone = timezone;
timezone = 0;
tzset();
}
#endif
tclockVal = clockVal;
timeDataPtr = TclpGetDate((TclpTime_t) tclockVal, useGMT);
/*
* Make a guess at the upper limit on the substituted string size
* based on the number of percents in the string.
*/
for (bufSize = 1, p = format; *p != '\0'; p++) {
if (*p == '%') {
bufSize += 40;
} else {
bufSize++;
}
}
Tcl_DStringInit(buffer);
Tcl_DStringSetLength(buffer, bufSize);
#ifndef HAVE_TM_ZONE
result = TclpStrftime(buffer.string, (unsigned int) bufSize, format,
timeDataPtr);
if (useGMT) {
if (savedTZEnv != NULL) {
Tcl_SetVar2(interp, env, TZ, savedTZEnv, TCL_GLOBAL_ONLY);
ckfree(savedTZEnv);
} else {
Tcl_UnsetVar2(interp, env, TZ, TCL_GLOBAL_ONLY);
}
timezone = savedTimeZone;
tzset();
}
Tcl_MutexUnlock(clockMutex);
#else
Tcl_MutexLock(clockMutex);
result = TclpStrftime(buffer.string, (unsigned int) bufSize, format,
timeDataPtr);
Tcl_MutexUnlock(clockMutex);
#endif /* not defined HAVE_TM_ZONE */
if (result == 0) {
/*
* A zero return is the error case (can also mean the strftime
* didn't get enough space to write into). We know it doesn't
* mean that we wrote zero chars because the check for an empty
* format string is above.
*/
Tcl_AppendStringsToObj(Tcl_GetObjResult(interp),
bad format string \, format, \, (char *) NULL);
return TCL_ERROR;
}
/*
* Convert the time to external encoding, in case we asked for
* a localized return value. [Bug: 3345]
*/
Tcl_DStringInit(uniBuffer);
Re: [AOLSERVER] segfault in ns_malloc, _smalloc
On Wednesday 30 October 2002 16:42, you wrote: Zoran - Is the bug in clock scan ... -gmt 1 or clock format ... -gmt 1? The code you posted is a change to the FormatClock function, which isn't used by clock scan. Oh boy, I'm really sorry for the confusion... It is the clock format ... -gmt 1, of course. The problem is the tzset() which patches over the TZ variable in the environment in order for time calculations in TclpStrftime() to be done correctly. Under Solaris, it does this unprotected, so it garbles the process env array. Cheers zoran
Re: [AOLSERVER] Good reading: Yahoo moving to PHP
On 2002.10.29, Kriston Rehberg [EMAIL PROTECTED] wrote: At first glance it sounded like a practical joke but this article is worth reading, anyway. AOLserver does support PHP through a module that is distributed with PHP. http://public.yahoo.com/~radwin/talks/yahoo-phpcon2002.htm It's disappointing to see AOLserver not even mentioned amongst the potential candidates. Considering Michael's theme was Yahoo! engineers like procedural languages ... Tcl and AOLserver should be perfect! Sigh. -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70)
Re: [AOLSERVER] Good reading: Yahoo moving to PHP
On 2002.10.30, Ayan George [EMAIL PROTECTED] wrote: Not to start a discussion about pthreads implementations, I just wanted to note that library implementations do not inherently perform poorly. Do you have any kind of evidence or benchmarks to support this? At the low end (single CPU, few threads) they're all pretty much the same but at high-end (4-way or 8-way CPU and 5,000 concurrent threads) you can pretty much watch userspace threads suck in a visibly measurable way. I think that's what Yahoo! is talking about with regard to their threading issues on FreeBSD. But, as it's been pointed out, Apache 2 is multithreaded, so ... I bet Yahoo! is just going to continue using, supporting and developing Apache 1.3 until FreeBSD thread support catches up. -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70)
Re: [AOLSERVER] Good reading: Yahoo moving to PHP
On Wednesday, October 30, 2002, at 11:39 AM, Dossy wrote: But, as it's been pointed out, Apache 2 is multithreaded, You can run Apache 2 with a threaded multiprocessing module (MPM), but you can also run one that uses a preforked process pool as well. There are at least 3 MPMs as of now, as far as I know. If you use the multi process MPM, you can move your existing Apache 1.3.x installation to 2.x with very little work.
Re: [AOLSERVER] segfault in ns_malloc, _smalloc
From: Zoran Vasiljevic [EMAIL PROTECTED] I will send you the changes to the clock code. I'm using the 8.3.4 for AOL3.4 but this part is same for 8.3.2 anyway. Did the changes you mention get submitted to tcl.sf.net in time for Tcl 8.4.1 ? -- Tcl - The glue of a new generation. URL: http://wiki.tcl.tk/ Larry W. Virden mailto:lvirden;cas.org URL: http://www.purl.org/NET/lvirden/ Even if explicitly stated to the contrary, nothing in this posting should be construed as representing my employer's opinions. --
Re: [AOLSERVER] segfault in ns_malloc, _smalloc
On Wednesday 30 October 2002 18:33, you wrote: From: Zoran Vasiljevic [EMAIL PROTECTED] I will send you the changes to the clock code. I'm using the 8.3.4 for AOL3.4 but this part is same for 8.3.2 anyway. Did the changes you mention get submitted to tcl.sf.net in time for Tcl 8.4.1 ? Yes. Even before 8.4.0 went out.
Re: [AOLSERVER] Good reading: Yahoo moving to PHP
On Wed, 30 Oct 2002, Dossy wrote: Do you have any kind of evidence or benchmarks to support this? Sorry, no benchmarks. I've read this several places and there is reasonable thought to back this up. Here is a relevant excerpt from the comp.programming.threads.faq: 6.2. Performance differences In terms of context switch time, user-space threads are the fastest, with two-level threads coming next (all other things being equal). However, if you have a multiprocessor, user-level threads can only be run on a single CPU, while both two-level and pure kernel-supported threads can be run on multiple CPUs simultaneously. - http://www.serpentine.com/~bos/threads-faq/#6-2-Performance-differences As I mentioned, a library threads implemenation CAN be more effecient -- that is on single CPU machines. Obviously, an implementation that allows threads to span CPUs will out perform one where all threads are bound to a single CPU. In fact, 1:1 and possibly 1:n implementation may be less ineffecient on a machine with one CPU. Of course, context switch time isn't the only factor in performance. Sorry if that sounded like, ``user threads on a 16 CPU machine can easily out perform 1:1 thread implementation on the same machine!'' Once again: I was just trying to say that user threads does not have to mean poor performance. :^) -Ayan At the low end (single CPU, few threads) they're all pretty much the same but at high-end (4-way or 8-way CPU and 5,000 concurrent threads) you can pretty much watch userspace threads suck in a visibly measurable way. I think that's what Yahoo! is talking about with regard to their threading issues on FreeBSD. But, as it's been pointed out, Apache 2 is multithreaded, so ... I bet Yahoo! is just going to continue using, supporting and developing Apache 1.3 until FreeBSD thread support catches up. -- Dossy
Re: [AOLSERVER] Good reading: Yahoo moving to PHP
On 2002.10.30, Ayan George [EMAIL PROTECTED] wrote: Once again: I was just trying to say that user threads does not have to mean poor performance. :^) Right. I don't think anyone necessarily disagrees with you. There's a multitude of factors involved in thread performance ... one big place is the memory allocator between threads, IIRC. Things like that might get overlooked when looking to scale up threaded applications ... -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on. (p. 70)
[AOLSERVER] AOLserver
I am using AOLserver 3.4 and PostgreSQL 7.2.1. Occasionally AOLserver will just crash. I get an error like this in the serverlog: [25/Oct/2002:15:50:00][1413.883783][-conn633-] Error: It has something to do with the database driver because I can duplicate the behavior if I do a query without single quotes '. Is this normal behavior? I would rather see a descriptive error about a failed query because it is difficult to debug this way. Nate Haggard
Re: [AOLSERVER] AOLserver
On Wed, Oct 30, 2002 at 04:16:08PM -0700, Nate Haggard wrote: I am using AOLserver 3.4 and PostgreSQL 7.2.1. Occasionally AOLserver will just crash. I get an error like this in the serverlog: [25/Oct/2002:15:50:00][1413.883783][-conn633-] Error: It has something to do with the database driver because I can duplicate the behavior if I do a query without single quotes '. Is this normal behavior? I would rather see a descriptive error about a failed query because it is difficult to debug this way. You probably have the buggy PostgreSQL driver. Grab the nspostgres recentely re-added to the AOLserver tree, or from openacs.org. -Roberto -- +|Roberto Mello -http://www.brasileiro.net/ |--+ + Computer Science Graduate Student, Utah State University + + USU Free Software GNU/Linux Club - http://fslc.usu.edu/ + You used this shareware for 5 years and 3 days now. PLEASE REGISTER!!!
