00000006.htm

一份很好的linux入门资料

when&nbsp;a&nbsp;normal&nbsp;I/O&nbsp;function&nbsp;like&nbsp;read()&nbsp;or&nbsp;write()&nbsp;completes.&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Available&nbsp;in&nbsp;Linux&nbsp;2.3.21&nbsp;or&nbsp;higher.&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;To&nbsp;use&nbsp;this,&nbsp;you&nbsp;choose&nbsp;a&nbsp;realtime&nbsp;signal&nbsp;number,&nbsp;mask&nbsp;that&nbsp;&nbsp;<BR>
signal&nbsp;and&nbsp;SIGIO&nbsp;with&nbsp;sigprocmask(),&nbsp;use&nbsp;fcntl(fd,&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;F_SETSIG,&nbsp;signum)&nbsp;on&nbsp;each&nbsp;fd,&nbsp;write&nbsp;a&nbsp;normal&nbsp;poll()&nbsp;outer&nbsp;&nbsp;<BR>
loop,&nbsp;and&nbsp;inside&nbsp;it,&nbsp;after&nbsp;you've&nbsp;handled&nbsp;all&nbsp;the&nbsp;fd's&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;noticed&nbsp;by&nbsp;poll(),&nbsp;you&nbsp;loop&nbsp;calling&nbsp;sigwaitinfo().&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;If&nbsp;sigwaitinfo&nbsp;returns&nbsp;your&nbsp;realtime&nbsp;signal,&nbsp;siginfo.si_fd&nbsp;and&nbsp;<BR>
&nbsp;siginfo.si_band&nbsp;give&nbsp;the&nbsp;same&nbsp;information&nbsp;as&nbsp;pollfd.fd&nbsp;and&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;pollfd.revents&nbsp;would&nbsp;after&nbsp;a&nbsp;call&nbsp;to&nbsp;poll(),&nbsp;so&nbsp;you&nbsp;handle&nbsp;the&nbsp;<BR>
&nbsp;i/o,&nbsp;and&nbsp;continue&nbsp;calling&nbsp;sigwaitinfo().&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;If&nbsp;sigwaitinfo&nbsp;returns&nbsp;a&nbsp;traditional&nbsp;SIGIO,&nbsp;the&nbsp;signal&nbsp;queue&nbsp;&nbsp;<BR>
overflowed,&nbsp;so&nbsp;you&nbsp;flush&nbsp;the&nbsp;signal&nbsp;queue&nbsp;by&nbsp;temporarily&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;changing&nbsp;the&nbsp;signal&nbsp;handler&nbsp;to&nbsp;SIG_DFL,&nbsp;and&nbsp;break&nbsp;back&nbsp;to&nbsp;&nbsp;<BR>
the&nbsp;outer&nbsp;poll()&nbsp;loop.&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;You&nbsp;can&nbsp;support&nbsp;older&nbsp;kernels&nbsp;by&nbsp;surrounding&nbsp;the&nbsp;sigwaitinfo&nbsp;&nbsp;<BR>
code&nbsp;with&nbsp;#if&nbsp;defined(LINUX_VERSION_CODE)&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&amp;&amp;&nbsp;(LINUX_VERSION_CODE&nbsp;&gt;=&nbsp;KERNEL_VERSION(2.3.21))&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;See&nbsp;Zach&nbsp;Brown's&nbsp;phhttpd&nbsp;for&nbsp;example&nbsp;code&nbsp;that&nbsp;uses&nbsp;this&nbsp;&nbsp;<BR>
feature,&nbsp;and&nbsp;deals&nbsp;with&nbsp;some&nbsp;of&nbsp;the&nbsp;gotchas,&nbsp;e.g.&nbsp;events&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;queued&nbsp;before&nbsp;an&nbsp;fd&nbsp;is&nbsp;dealt&nbsp;with&nbsp;or&nbsp;closed,&nbsp;but&nbsp;arriving&nbsp;&nbsp;<BR>
afterwards.&nbsp;&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;SIGIO&nbsp;(see&nbsp;glibc&nbsp;doc&nbsp;or&nbsp;BSD&nbsp;Sockets&nbsp;doc)&nbsp;--&nbsp;doesn't&nbsp;tell&nbsp;you&nbsp;&nbsp;<BR>
which&nbsp;handle&nbsp;needs&nbsp;servicing,&nbsp;so&nbsp;it&nbsp;seems&nbsp;kind&nbsp;of&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;coarse.&nbsp;Used&nbsp;by&nbsp;the&nbsp;Linux&nbsp;F_SETSIG/aio_&nbsp;implementation&nbsp;as&nbsp;a&nbsp;&nbsp;<BR>
fallback&nbsp;when&nbsp;the&nbsp;realtime&nbsp;signal&nbsp;queue&nbsp;overflows.&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Here's&nbsp;an&nbsp;example&nbsp;of&nbsp;its&nbsp;use.&nbsp;(Was&nbsp;partly&nbsp;broken&nbsp;in&nbsp;Linux&nbsp;&nbsp;<BR>
kernels&nbsp;2.2.0&nbsp;-&nbsp;2.2.7,&nbsp;fixed&nbsp;in&nbsp;2.2.8.)&nbsp;&nbsp;<BR>
&nbsp;<BR>
Richard&nbsp;Gooch&nbsp;has&nbsp;written&nbsp;a&nbsp;paper&nbsp;discussing&nbsp;these&nbsp;options.&nbsp;&nbsp;<BR>
Interesting&nbsp;reading.&nbsp;&nbsp;<BR>
&nbsp;<BR>
The&nbsp;Apache&nbsp;mailing&nbsp;lists&nbsp;have&nbsp;some&nbsp;interesting&nbsp;posts&nbsp;about&nbsp;why&nbsp;they&nbsp;&nbsp;<BR>
prefer&nbsp;not&nbsp;to&nbsp;use&nbsp;select()&nbsp;(basically,&nbsp;they&nbsp;think&nbsp;that&nbsp;makes&nbsp;<BR>
plugins&nbsp;harder).&nbsp;Still,&nbsp;they're&nbsp;planning&nbsp;to&nbsp;use&nbsp;&nbsp;<BR>
select()/poll()/sendfile()&nbsp;for&nbsp;static&nbsp;requests&nbsp;in&nbsp;Apache&nbsp;2.0.&nbsp;&nbsp;<BR>
&nbsp;<BR>
Mark&nbsp;Russinovich&nbsp;wrote&nbsp;an&nbsp;editorial&nbsp;and&nbsp;an&nbsp;article&nbsp;discussing&nbsp;I/O&nbsp;&nbsp;<BR>
strategy&nbsp;issues&nbsp;in&nbsp;the&nbsp;2.2&nbsp;Linux&nbsp;kernel.&nbsp;Worth&nbsp;reading,&nbsp;even&nbsp;he&nbsp;<BR>
seems&nbsp;misinformed&nbsp;on&nbsp;some&nbsp;points.&nbsp;In&nbsp;particular,&nbsp;he&nbsp;seems&nbsp;to&nbsp;think&nbsp;&nbsp;<BR>
that&nbsp;Linux&nbsp;2.2's&nbsp;asyncrhonous&nbsp;I/O&nbsp;(see&nbsp;F_SETSIG&nbsp;above)&nbsp;<BR>
doesn't&nbsp;notify&nbsp;the&nbsp;user&nbsp;process&nbsp;when&nbsp;data&nbsp;is&nbsp;ready,&nbsp;only&nbsp;when&nbsp;new&nbsp;&nbsp;<BR>
connections&nbsp;arrive.&nbsp;This&nbsp;seems&nbsp;like&nbsp;a&nbsp;bizarre&nbsp;misunderstanding.&nbsp;<BR>
See&nbsp;also&nbsp;comments&nbsp;on&nbsp;an&nbsp;earlier&nbsp;draft,&nbsp;a&nbsp;rebuttal&nbsp;from&nbsp;Mingo,&nbsp;&nbsp;<BR>
Russinovich's&nbsp;comments&nbsp;of&nbsp;2&nbsp;May&nbsp;1999,&nbsp;a&nbsp;rebuttal&nbsp;from&nbsp;Alan&nbsp;Cox,&nbsp;<BR>
and&nbsp;various&nbsp;posts&nbsp;to&nbsp;linux-kernel.&nbsp;I&nbsp;suspect&nbsp;he&nbsp;was&nbsp;trying&nbsp;to&nbsp;say&nbsp;that&nbsp;&nbsp;<BR>
Linux&nbsp;doesn't&nbsp;support&nbsp;asynchronous&nbsp;disk&nbsp;I/O,&nbsp;which&nbsp;is&nbsp;<BR>
somewhat&nbsp;true.&nbsp;&nbsp;<BR>
&nbsp;<BR>
There&nbsp;was&nbsp;an&nbsp;interesting&nbsp;discussion&nbsp;on&nbsp;linux-kernel&nbsp;in&nbsp;September&nbsp;1999&nbsp;&nbsp;<BR>
titled&nbsp;&quot;&gt;&nbsp;15,000&nbsp;Simultaneous&nbsp;Connections&quot;.&nbsp;(second&nbsp;<BR>
week,&nbsp;third&nbsp;week)&nbsp;Highlights:&nbsp;&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Ed&nbsp;Hall&nbsp;posted&nbsp;a&nbsp;few&nbsp;notes&nbsp;on&nbsp;his&nbsp;experiences;&nbsp;he's&nbsp;achieved&nbsp;&nbsp;<BR>
＞<I>1000&nbsp;connects/second&nbsp;on&nbsp;a&nbsp;UP&nbsp;P2/333&nbsp;running&nbsp;Solaris.&nbsp;His&nbsp;</I><BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;code&nbsp;used&nbsp;a&nbsp;small&nbsp;pool&nbsp;of&nbsp;threads&nbsp;(1&nbsp;or&nbsp;2&nbsp;per&nbsp;CPU)&nbsp;each&nbsp;managing&nbsp;&nbsp;<BR>
a&nbsp;large&nbsp;number&nbsp;of&nbsp;clients&nbsp;using&nbsp;&quot;an&nbsp;event-based&nbsp;model&quot;.&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Mike&nbsp;Jagdis&nbsp;posted&nbsp;an&nbsp;analysis&nbsp;of&nbsp;poll/select&nbsp;overhead,&nbsp;and&nbsp;said&nbsp;&nbsp;<BR>
&quot;The&nbsp;current&nbsp;select/poll&nbsp;implementation&nbsp;can&nbsp;be&nbsp;improved&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;significantly,&nbsp;especially&nbsp;in&nbsp;the&nbsp;blocking&nbsp;case,&nbsp;but&nbsp;the&nbsp;overhead&nbsp;&nbsp;<BR>
will&nbsp;still&nbsp;increase&nbsp;with&nbsp;the&nbsp;number&nbsp;of&nbsp;descriptors&nbsp;because&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;select/poll&nbsp;does&nbsp;not,&nbsp;and&nbsp;cannot,&nbsp;remember&nbsp;what&nbsp;descriptors&nbsp;are&nbsp;&nbsp;<BR>
interesting.&nbsp;This&nbsp;would&nbsp;be&nbsp;easy&nbsp;to&nbsp;fix&nbsp;with&nbsp;a&nbsp;new&nbsp;API.&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Suggestions&nbsp;are&nbsp;welcome...&quot;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Mike&nbsp;posted&nbsp;about&nbsp;his&nbsp;work&nbsp;on&nbsp;improving&nbsp;select()&nbsp;and&nbsp;poll().&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Mike&nbsp;posted&nbsp;a&nbsp;bit&nbsp;about&nbsp;a&nbsp;possible&nbsp;API&nbsp;to&nbsp;replace&nbsp;poll()/select():&nbsp;<BR>
&nbsp;&quot;How&nbsp;about&nbsp;a&nbsp;'device&nbsp;like'&nbsp;API&nbsp;where&nbsp;you&nbsp;write&nbsp;'pollfd&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;like'&nbsp;structs,&nbsp;the&nbsp;'device'&nbsp;listens&nbsp;for&nbsp;events&nbsp;and&nbsp;delivers&nbsp;'pollfd&nbsp;<BR>
&nbsp;like'&nbsp;structs&nbsp;representing&nbsp;them&nbsp;when&nbsp;you&nbsp;read&nbsp;it?&nbsp;...&nbsp;&quot;&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Rogier&nbsp;Wolff&nbsp;suggested&nbsp;using&nbsp;&quot;the&nbsp;API&nbsp;that&nbsp;the&nbsp;digital&nbsp;guys&nbsp;&nbsp;<BR>
suggested&quot;,&nbsp;<A HREF="http://www.cs.rice.edu/~gaurav/papers/usenix99.ps">http://www.cs.rice.edu/~gaurav/papers/usenix99.ps</A>&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Joerg&nbsp;Pommnitz&nbsp;pointed&nbsp;out&nbsp;that&nbsp;any&nbsp;new&nbsp;API&nbsp;along&nbsp;these&nbsp;lines&nbsp;&nbsp;<BR>
should&nbsp;be&nbsp;able&nbsp;to&nbsp;wait&nbsp;for&nbsp;not&nbsp;just&nbsp;file&nbsp;descriptor&nbsp;events,&nbsp;but&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;also&nbsp;signals&nbsp;and&nbsp;maybe&nbsp;SYSV-IPC.&nbsp;Our&nbsp;synchronization&nbsp;primitives&nbsp;&nbsp;<BR>
should&nbsp;certainly&nbsp;be&nbsp;able&nbsp;to&nbsp;do&nbsp;what&nbsp;Win32's&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;WaitForMultipleObjects&nbsp;can,&nbsp;at&nbsp;least.&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Stephen&nbsp;Tweedie&nbsp;asserted&nbsp;that&nbsp;the&nbsp;combination&nbsp;of&nbsp;F_SETSIG,&nbsp;queued&nbsp;&nbsp;<BR>
realtime&nbsp;signals,&nbsp;and&nbsp;sigwaitinfo()&nbsp;was&nbsp;a&nbsp;superset&nbsp;of&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;the&nbsp;API&nbsp;proposed&nbsp;in&nbsp;<A HREF="http://www.cs.rice.">http://www.cs.rice.</A>&nbsp;<BR>
edu/~gaurav/papers/usenix99.ps.&nbsp;He&nbsp;also&nbsp;mentions&nbsp;that&nbsp;you&nbsp;keep&nbsp;the&nbsp;&nbsp;<BR>
signal&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;blocked&nbsp;at&nbsp;all&nbsp;times&nbsp;if&nbsp;you're&nbsp;interested&nbsp;in&nbsp;performance;&nbsp;instead&nbsp;&nbsp;<BR>
of&nbsp;the&nbsp;signal&nbsp;being&nbsp;delivered&nbsp;asynchronously,&nbsp;the&nbsp;process&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;grabs&nbsp;the&nbsp;next&nbsp;one&nbsp;from&nbsp;the&nbsp;queue&nbsp;with&nbsp;sigwaitinfo().&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Jayson&nbsp;Nordwick&nbsp;compared&nbsp;completion&nbsp;ports&nbsp;with&nbsp;the&nbsp;F_SETSIG&nbsp;&nbsp;<BR>
synchronous&nbsp;event&nbsp;model,&nbsp;and&nbsp;concluded&nbsp;they're&nbsp;pretty&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;similar.&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Alan&nbsp;Cox&nbsp;noted&nbsp;that&nbsp;an&nbsp;older&nbsp;rev&nbsp;of&nbsp;SCT's&nbsp;SIGIO&nbsp;patch&nbsp;is&nbsp;included&nbsp;&nbsp;<BR>
in&nbsp;2.3.18ac.&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Jordan&nbsp;Mendelson&nbsp;posted&nbsp;some&nbsp;example&nbsp;code&nbsp;showing&nbsp;how&nbsp;to&nbsp;use&nbsp;&nbsp;<BR>
F_SETSIG.&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Stephen&nbsp;C.&nbsp;Tweedie&nbsp;continued&nbsp;the&nbsp;comparison&nbsp;of&nbsp;completion&nbsp;ports&nbsp;and&nbsp;<BR>
&nbsp;F_SETSIG,&nbsp;and&nbsp;noted:&nbsp;&quot;With&nbsp;a&nbsp;signal&nbsp;dequeuing&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;mechanism,&nbsp;your&nbsp;application&nbsp;is&nbsp;going&nbsp;to&nbsp;get&nbsp;signals&nbsp;destined&nbsp;for&nbsp;&nbsp;<BR>
various&nbsp;library&nbsp;components&nbsp;if&nbsp;libraries&nbsp;are&nbsp;using&nbsp;the&nbsp;same&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;mechanism,&quot;&nbsp;but&nbsp;the&nbsp;library&nbsp;can&nbsp;set&nbsp;up&nbsp;its&nbsp;own&nbsp;signal&nbsp;handler,&nbsp;so&nbsp;&nbsp;<BR>
this&nbsp;shouldn't&nbsp;affect&nbsp;the&nbsp;program&nbsp;(much).&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Doug&nbsp;Royer&nbsp;noted&nbsp;that&nbsp;he'd&nbsp;gotten&nbsp;100,000&nbsp;connections&nbsp;on&nbsp;Solaris&nbsp;&nbsp;<BR>
2.6&nbsp;while&nbsp;he&nbsp;was&nbsp;working&nbsp;on&nbsp;the&nbsp;Sun&nbsp;calendar&nbsp;server.&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Others&nbsp;chimed&nbsp;in&nbsp;with&nbsp;estimates&nbsp;of&nbsp;how&nbsp;much&nbsp;RAM&nbsp;that&nbsp;would&nbsp;&nbsp;<BR>
require&nbsp;on&nbsp;Linux,&nbsp;and&nbsp;what&nbsp;bottlenecks&nbsp;would&nbsp;be&nbsp;hit.&nbsp;&nbsp;<BR>
&nbsp;<BR>
Interesting&nbsp;reading!&nbsp;&nbsp;<BR>
&nbsp;<BR>
Limits&nbsp;on&nbsp;open&nbsp;filehandles&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Any&nbsp;Unix:&nbsp;the&nbsp;limits&nbsp;set&nbsp;by&nbsp;ulimit&nbsp;or&nbsp;setrlimit.&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Solaris:&nbsp;see&nbsp;the&nbsp;Solaris&nbsp;FAQ,&nbsp;question&nbsp;3.45.&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;FreeBSD:&nbsp;use&nbsp;sysctl&nbsp;-w&nbsp;kern.maxfiles=nnnn&nbsp;to&nbsp;raise&nbsp;limit&nbsp;&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Linux:&nbsp;See&nbsp;Bodo&nbsp;Bauer's&nbsp;/proc&nbsp;documentation.&nbsp;On&nbsp;current&nbsp;2.2.x&nbsp;&nbsp;<BR>
kernels,&nbsp;&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;echo&nbsp;32768&nbsp;&gt;&nbsp;/proc/sys/fs/file-max&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;echo&nbsp;65536&nbsp;&gt;&nbsp;/proc/sys/fs/inode-max&nbsp;<BR>
&nbsp;<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;increases&nbsp;the&nbsp;system&nbsp;limit&nbsp;on&nbsp;open&nbsp;files,&nbsp;and&nbsp;&nbsp;<BR>
&nbsp;<BR>