<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Regarding HPUX10.2 in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/regarding-hpux10-2/m-p/2445263#M769583</link>
    <description>I found the following information extracted from an earlier call, but I am not sure if it is exactly your situation.   Worth reviewing anyway:&lt;BR /&gt;"&lt;BR /&gt;There is a documented workaround for an accept()/system() call problem.  &lt;BR /&gt;It is to use an fcntl call to set the close-on-exec flag before calling exec() (which select() is a thin wrapper for anyway; fork/exec/wait).  This is documented in "Programming with Threads on HP-UX" in section 3.2.1.6 on page 3-16.  &lt;BR /&gt;The other option would be to avoid using the select call and calling exec directly&lt;BR /&gt;rather than the exec wrapper, also documented in the same section.&lt;BR /&gt;The fcntl can be used soon after the socket is created.&lt;BR /&gt;  .......&lt;BR /&gt;     sock = socket(AF_INET,SOCK_STREAM, 0);&lt;BR /&gt;     if (sock == -1) {&lt;BR /&gt;          fprintf(stderr, "socket failed, errno %dn", errno);&lt;BR /&gt;          return -1;&lt;BR /&gt;          }&lt;BR /&gt;     fcntl(sock,F_SETFD,FD_CLOEXEC);&lt;BR /&gt;    ......&lt;BR /&gt;cma___pre_exec_cleanup() (internal routine) sets the file-descriptors&lt;BR /&gt;to blocking mode.&lt;BR /&gt;&lt;BR /&gt;A change in the code would involve calling set_blocking every time in&lt;BR /&gt;the accept() wrapper and that may lead to decreased performance.  For&lt;BR /&gt;this reason we recommend close-on-exec as a documented workaround.&lt;BR /&gt;"&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;There is some excellent threads FAQs and manuals info at URL:&lt;BR /&gt;&lt;A href="http://devresource.hp.com/" target="_blank"&gt;http://devresource.hp.com/&lt;/A&gt;&lt;BR /&gt;&lt;BR /&gt;You must go there....there is some good detailed info.&lt;BR /&gt;&lt;BR /&gt;I hope this helps.&lt;BR /&gt;</description>
    <pubDate>Fri, 15 Sep 2000 14:43:45 GMT</pubDate>
    <dc:creator>Pete Conneely</dc:creator>
    <dc:date>2000-09-15T14:43:45Z</dc:date>
    <item>
      <title>Regarding HPUX10.2</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/regarding-hpux10-2/m-p/2445262#M769582</link>
      <description>Observation - Execution of 'system()' system call after the 'accept()' system call results in&lt;BR /&gt;the blocking of threads existing in that process on executing another 'accept()' call.&lt;BR /&gt;&lt;BR /&gt;Detailed Explanation - &lt;BR /&gt;      The RemoteServer('server' executable) is started. The RemoteServer accepts connections from a client. When the RemoteServer accepts a connection for the first time, a parallel thread is started which isan infinite loop. After starting the thread, a "system()" function is executed.The next connection request by the client results in the thread in the RemoteServer getting blocked.&lt;BR /&gt;       Other Operating systems like HPUX 11.0,Sun Solaris 2.6 and Aix4.2 do not block the&lt;BR /&gt;thread after any number of connections. &lt;BR /&gt;      However, removing the "system()" function from the code on HPUX10.2 allows further &lt;BR /&gt;connections without blocking or killing the thread.&lt;BR /&gt;&lt;BR /&gt;Note : We use cma library to compile the RemoteServer code to support pthread_create call in&lt;BR /&gt;HPUX10.2 (ie. we compile the code using the -lcma option).&lt;BR /&gt;&lt;BR /&gt;Query -&lt;BR /&gt;1)     Is there a relation between the "accept" system call and the "system" system call which &lt;BR /&gt;results in any thread existing in that process from getting blocked or killed ?&lt;BR /&gt;2)     Is the above phenomenon because of the usage of cma library to support pthread_create ?&lt;BR /&gt;3)     Do we have to use any particular value for the attribute parameter in the pthread_create&lt;BR /&gt;call ? (We use pthread_attr_default in our pthread_create call.)&lt;BR /&gt;      &lt;BR /&gt;Note : Please refer to file ServerCode.doc for diagramatic explanation&lt;BR /&gt;of problem area in code.</description>
      <pubDate>Thu, 14 Sep 2000 05:55:01 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/regarding-hpux10-2/m-p/2445262#M769582</guid>
      <dc:creator>Soumya_2</dc:creator>
      <dc:date>2000-09-14T05:55:01Z</dc:date>
    </item>
    <item>
      <title>Re: Regarding HPUX10.2</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/regarding-hpux10-2/m-p/2445263#M769583</link>
      <description>I found the following information extracted from an earlier call, but I am not sure if it is exactly your situation.   Worth reviewing anyway:&lt;BR /&gt;"&lt;BR /&gt;There is a documented workaround for an accept()/system() call problem.  &lt;BR /&gt;It is to use an fcntl call to set the close-on-exec flag before calling exec() (which select() is a thin wrapper for anyway; fork/exec/wait).  This is documented in "Programming with Threads on HP-UX" in section 3.2.1.6 on page 3-16.  &lt;BR /&gt;The other option would be to avoid using the select call and calling exec directly&lt;BR /&gt;rather than the exec wrapper, also documented in the same section.&lt;BR /&gt;The fcntl can be used soon after the socket is created.&lt;BR /&gt;  .......&lt;BR /&gt;     sock = socket(AF_INET,SOCK_STREAM, 0);&lt;BR /&gt;     if (sock == -1) {&lt;BR /&gt;          fprintf(stderr, "socket failed, errno %dn", errno);&lt;BR /&gt;          return -1;&lt;BR /&gt;          }&lt;BR /&gt;     fcntl(sock,F_SETFD,FD_CLOEXEC);&lt;BR /&gt;    ......&lt;BR /&gt;cma___pre_exec_cleanup() (internal routine) sets the file-descriptors&lt;BR /&gt;to blocking mode.&lt;BR /&gt;&lt;BR /&gt;A change in the code would involve calling set_blocking every time in&lt;BR /&gt;the accept() wrapper and that may lead to decreased performance.  For&lt;BR /&gt;this reason we recommend close-on-exec as a documented workaround.&lt;BR /&gt;"&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;There is some excellent threads FAQs and manuals info at URL:&lt;BR /&gt;&lt;A href="http://devresource.hp.com/" target="_blank"&gt;http://devresource.hp.com/&lt;/A&gt;&lt;BR /&gt;&lt;BR /&gt;You must go there....there is some good detailed info.&lt;BR /&gt;&lt;BR /&gt;I hope this helps.&lt;BR /&gt;</description>
      <pubDate>Fri, 15 Sep 2000 14:43:45 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/regarding-hpux10-2/m-p/2445263#M769583</guid>
      <dc:creator>Pete Conneely</dc:creator>
      <dc:date>2000-09-15T14:43:45Z</dc:date>
    </item>
    <item>
      <title>Re: Regarding HPUX10.2</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/regarding-hpux10-2/m-p/2445264#M769584</link>
      <description>Hi Peter,&lt;BR /&gt;   Thanks for your suggestion about using fcntl(). Our program did work for the second accept(). It was very kind of you to give us this solution &lt;BR /&gt;Thank you&lt;BR /&gt;Soumya&lt;BR /&gt;</description>
      <pubDate>Wed, 20 Sep 2000 08:01:03 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/regarding-hpux10-2/m-p/2445264#M769584</guid>
      <dc:creator>Soumya_2</dc:creator>
      <dc:date>2000-09-20T08:01:03Z</dc:date>
    </item>
  </channel>
</rss>

