John Kominetz on 6 Dec 2011 14:26:06 -0800
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
Re: [Philadelphia-pm] Reminder: tech meeting Monday night, December 5
- From: John Kominetz <email@example.com>
- To: firstname.lastname@example.org
- Subject: Re: [Philadelphia-pm] Reminder: tech meeting Monday night, December 5
- Date: Tue, 6 Dec 2011 17:25:29 -0500
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=nKmVHIKOnz26+soF7f0s586CYYg2u1lQv94SC05pTmU=; b=gOPpxl13NWtxjHMXZji+NFVUXLYzvAmjnNIfnFYX46RoN1OSkYmeGtHBDDf6FG7qBb Y0yNZvuh0u3qrmiG3lwXBls/9sK9f3YE8CbzMtxhug6GD7hbTG8Vi+bSxQk8M9c6Xhn6 LO43z2CCOy36KLKvmdI1wXMveup64piXLgplo=
- List-archive: <http://mail.pm.org/pipermail/philadelphia-pm>
- Sender: email@example.com
I have to say I was a little confused from the start because of the statement that each thread was a complete interpreter. I "interpreted" that as each thread was actually a separate PROCESS, and that all this was hijacking threads as a metaphor for inter-process communication. So I wrote a test with five threads that each waited for 30 seconds and watched the activity monitor. It reported one perl process with six threads, running for 30 seconds. End of Duh.
That also renders moot my question about "threads" surviving beyond the lifetime of the caller. Being real (OS) threads, that's not possible. Changing my test from join() to detach(), the threads die unexpected, untimely deaths as the process comes crashing down upon them.
Philadelphia-pm mailing list