Linux-Development-Apps Digest #460, Volume #7     Fri, 8 Jun 01 14:13:18 EDT

Contents:
  common getpid() for threads? (Graeme Roy)
  threads, signals and C++ class (Etienne Maitre)
  Re: accept freezes ("Nils O. Selåsdal")
  Re: launching a C program from a startup script ("Nils O. Selåsdal")
  Re: common getpid() for threads? (Rolf Magnus)
  Re: which library for GUI is best? (Mark Hatch)
  Re: which library for GUI is best? (Bob Beaty)
  Re: Matt Blaze's CFS on Linux - readdir problem. (Kevin Buhr)
  Re: which library for GUI is best? (Jan Panteltje)
  Re: inexplicable error (David McCaw)
  Re: which library for GUI is best? ([EMAIL PROTECTED])
  Re: =?iso-8859-1?Q?=EF=20=F7=E9=EE=E4=F9=21=21=21=21=21?= (Jan Atle Ramsli)
  stdout troubles ("Clifton T. Sharp Jr.")

----------------------------------------------------------------------------

From: Graeme Roy <[EMAIL PROTECTED]>
Subject: common getpid() for threads?
Date: Fri, 8 Jun 2001 10:13:05 +0100

Hi,

Not sure if this is a commonly-asked question, but how can I obtain the
process id for multiple threads in a common process on Linux?  On most
other UNIX platforms, getpid() returns the process id of the process under
which a thread is running.  On Linux, getpid() returns the process id of
the current thread (presumably because threads are a special form of LWP
on Linux).

However, this knowledge doesn't help me much in the library I have
written, as I must know when a process has forked, and the most portable
way of doing this is to compare the result of getpid() with a 
previously-stored value.  I suppose pthread_atfork() might help but I was
wondering if a function exists which provides even some ability to compare
if threads belong to the same process id.

Thanks,

Graeme.


------------------------------

From: Etienne Maitre <[EMAIL PROTECTED]>
Subject: threads, signals and C++ class
Date: Fri, 8 Jun 2001 18:42:06 +0900

Hello,
I have a little (pure rethoric, in fact it's big) problem. Here is the point:
I must have a class which should contain 2 methods:
   - one must be a thread and run continously
   - the other must be a signal handler called regularly by the main

I create my instance, call the thread, everything work fine except that in my main, 
the signal SIGALRM is never received until the thread is finished!
And for sure, the specs are: "MyEmbThread is implemented by a third party and can 
contain loops" meaning that I can't ask the "3rd party" to put sleeps every time...
I tryed with LinuxThread and C++ Threads libs...same problem. And I can't multiply my 
sig handlers to embedded them in my class.

Thx for any help...

Etienne


Here is my main:


TYamabico pYama;

void *MyEmbThread(void *arg)
{
   while(1)
      std::cout << "MyEmbThread" << std::endl;
}

void MyHandler(int iSig)
{
   std::cout << "MyHandler" << std::endl;
   pYama->SigHandler();
}

int main(void)
{
   struct timeval t1 = { 1, 0 };
   struct timeval t2 = { 1, 0 };
   struct itimerval t3 = {t1, t2};
   pYama = new TYamabico();
   pYama->Go();   /* run the thread which is MyEmbThread() */
   signal(SIGALRM, MyHandler);
   setitimer(ITIMER_REAL, &t3, NULL);
   while(1)
   {
   }
   return 0;
}

------------------------------

From: "Nils O. Selåsdal" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.system
Subject: Re: accept freezes
Date: Fri, 8 Jun 2001 13:28:59 +0200


"Christophe Dore" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Hi,
>
> I have a multithreaded small http server that has the following
> problem :
> after a big bunch of accept (around 400,000), accept freezes.
>
> I mean that you can telnet the server, send a line or two, but the
> accept function does not returns, (so the data transfer socket is not
> treated by the server). furthermore, what is strange is that when I
do
> "netstat" on the server side, I see the data transfer socket in
> ESTABLISHED state...
>
> It seems that the operating system has accepted the connection, but
> has not provided it to the process....
>
> Any idea of can lead to this ?
> Any idea, hint, ... is welcome !! :-)
You do remember to close the socket when the client is done ?
you can check the /proc/<pid of progam> filesystem to see iif you have
filedescriptor leaks.




------------------------------

From: "Nils O. Selåsdal" <[EMAIL PROTECTED]>
Subject: Re: launching a C program from a startup script
Date: Fri, 8 Jun 2001 13:35:07 +0200


"tony" <[EMAIL PROTECTED]> wrote in message
news:nVLT6.41752$[EMAIL PROTECTED]...
>
>
>
> exec question
>
> From:
>
> tony <[EMAIL PROTECTED]>
>
> Date:
>
> Thursday 07 June 2001 08:21:05
>
> Groups:
>
> comp.unix.shell
>
>
>
> no references
>
>
>
> I wrote a small C program to extract caller id from my modem upon
phone
> calls. Once excuted cid (my caller ID program) will run continuously
in the
> background. I am going to start it on boot using the rc.local startup
> script. My question is how do I code the line that launchs cid from
> rc.local.
>
> I am trying this line in rc.local =>
>  [ -x /usr/sbin/cid ] &&  exec /usr/sbin/cid &
>
> This is the last line in rc.local.
>
> If if just use /usr/sbin/cid  (without the exec) my theory is that
the
> script rc.local will never finish since it will be waiting on my C
program
> cid to return which it never will since it runs continueosly waiting
for
> phone calls. So instead I pre-pend exec to  cid so rc.local is
replaced in
> the process place by cid allowing rc.local to terminate when
finished. Or
> would just using & afer cid (/usr/sbin/cid & ) suffice?
>
> Am I correct in my assumptions and proposed solutions. Any
suggestions on a
> better way of dealing with this?
Yes,
You should write your program to act as a daemon, call daemon();
somewhere soon in
your main function.




------------------------------

From: Rolf Magnus <[EMAIL PROTECTED]>
Subject: Re: common getpid() for threads?
Date: Fri, 08 Jun 2001 14:29:03 +0200

Graeme Roy wrote:

> Not sure if this is a commonly-asked question, but how can I obtain the
> process id for multiple threads in a common process on Linux?  On most
> other UNIX platforms, getpid() returns the process id of the process under
> which a thread is running.  On Linux, getpid() returns the process id of
> the current thread (presumably because threads are a special form of LWP
> on Linux).

The linux scheduler just treats threads as different processes, and so each 
one has it's own pid.

> However, this knowledge doesn't help me much in the library I have
> written, as I must know when a process has forked, and the most portable
> way of doing this is to compare the result of getpid() with a
> previously-stored value.  I suppose pthread_atfork() might help but I was
> wondering if a function exists which provides even some ability to compare
> if threads belong to the same process id.

Threads are created using the clone system call under linux, which is the 
same as fork with the exception that clone has some options so the 
processes can share resources. So they just are different processes.
Btw: It's most often a bad idea to use fork() in a threaded program if you 
don't use the forked copy to just exec() another program.

------------------------------

From: Mark Hatch <[EMAIL PROTECTED]>
Subject: Re: which library for GUI is best?
Date: 08 Jun 2001 13:22:47 GMT

As others have said, depends on what your goals are. The three main choices
are:

GTK+ - used as the basis of Gnome
QT - used as the basis of KDE
Motif - been around longer and used by most commercial UNIX applications

GTK and Motif are C based. QT is C++ and their commercial version runs on
Windows as well as Linux.There is a GTK-- and ViewKit www.viewkit.com) if
you want to use C++ with GTK+ and Motif respectively. GTK and Motif can be
used with proprietary, closed source applications at no charge. QT is
available under GPL (which means you need to open source anything you build
with it) and under a commercial license (i.e., you get to pay $$$'s if you
want to keep your source closed).

Some would argue that QT and GTK+ are slightly easier to learn than Motif
because it is a single toolkit. Motif is really a combination of Xt and a
set of Widgets (i.e. Motif) and you will find your programs using routines
from several libraries to create a GUI. The flip side of this ease of use
is that Motif has been tested to the limits with real applications with
complicated GUIs. Some customers I talk to really like the wide selection
of GTK+/QT widgets. But others fear that each lacks the depth of API and
control offered by Motif (and of course there are free widgets for Motif
too).

URLs:

GTK+: www.gtk.org
QT: www.trolltech.com
Motif: www.motifzone.net

Regards,

Mark

Uwe Bosse wrote:

> I want to write applications with a GUI for Linux system.
> There seem to be many C or C++ libraries that provide an access to the
> X-Server
> and functions to open Windows with Scrollbars to present lists and
> buttons and all that
> stuff.
>
> I found, for example, the Gimp Toolkit Gtk. (and its C++-Wrapper gtk--)
> Is it worth to spend a lot of time to learn how to use it?
> Or is there something better? (Something better could be a library, to
> which there exists a
> good tutorial)
>
> Thanks in advance, Uwe.


------------------------------

From: [EMAIL PROTECTED] (Bob Beaty)
Subject: Re: which library for GUI is best?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 08 Jun 2001 13:34:23 GMT

Uwe Bosse wrote:
> I want to write applications with a GUI for Linux system.

>From this, you'll be safe with Qt or GTK - it's a matter of preference or 
religious affiliation :)

> I found, for example, the Gimp Toolkit Gtk. (and its C++-Wrapper gtk--)
> Is it worth to spend a lot of time to learn how to use it? 

I think so, but that's because I am in the RedHat/GNOME/GTK camp, there 
are probably just as many KDE/Qt camp, so you won't be alone either way.

No one is clearly technically superior for very long. They keep moving 
and it's going to be a pain to stay current in both, so go with one and 
let that be that.

I chose my path because of my belief in CORBA and how it's enbraced by 
GNOME... but that's just me.

                        Thanks,
                          Bob   ([EMAIL PROTECTED]) 
                        The Man from S.P.U.D. 
                        We will write no code before it's designed.  


------------------------------

From: [EMAIL PROTECTED] (Kevin Buhr)
Crossposted-To: 
comp.os.linux.security,comp.os.linux.misc,comp.os.linux.development.system
Subject: Re: Matt Blaze's CFS on Linux - readdir problem.
Date: 08 Jun 2001 09:10:33 -0500

"Binesh Bannerjee" <[EMAIL PROTECTED]> writes:
>
>       if you read a large CFS directory with readdir it doesn't get
> all of the files, but readdir64 will work... Has anyone else
> had this problem, and if so, how do I go about fixing it?

It's a kernel/C-library bug that's difficult to fix completely.  The C
library does some fancy double-buffering in getdents(2) and so must
occassionally lseek on directories behind the scenes.  When reading
from NFS filesystems whose files have large (>0x8000000) NFS cookies,
it will occassionally issue directory lseeks to negative offsets
without checking for an error return value.  This is highly dependent
on internal C library buffer sizes, and will result in silently
disappearing files that vary from application to application.  For
NFSv2, you can fix this particular problem by having the C library
llseek in this situation; for NFSv3---where the cookies are 64 bits,
it'll still be broken

Note that this isn't normally a data-destroying bug---your files are
still there; it's just that some applications won't "see" some files.
"rm -rf" might give you a mysterious "directory not empty"; or after a
"mv * elsewhere", you might be surprised to discover the current
directory is still full of files that were missed on the first pass.

There's more on this in a "linux-kernel" thread with subject:

        negative NFS cookies: bad C library or bad kernel?

dated December 2, 2000.

The easiest fix is to modify CFS to use small NFS cookies.  CFS
actually uses small host-endian cookies that, on little-endian
architectures, become large cookies in NFS space.  This isn't a CFS
*bug*: cookies are supposed to be arbitrary.  However, it just happens
to tickle this Linux bug, and we can "fix" it by having CFS convert
cookie values to network byte order.

I've enclosed a patch against Debian CFS 1.3.3-9; it will apply
against vanilla CFS 1.3.3 with some fuzz.  Note that this modification
won't introduce any compatibility problems with existing or new CFS
directories---it only changes the values of the temporary cookies
passed between the CFS server and the kernel, not anything to do with
the CFS storage format.  As always, test on a trash CFS directory
before trying it on your pr0n collection or anti-government tract
archive.

Kevin <[EMAIL PROTECTED]>

                        *       *       *

diff -ru cfs-1.3.3/cfs_nfs.c cfs-1.3.3-new/cfs_nfs.c
--- cfs-1.3.3/cfs_nfs.c Wed Jun  6 00:37:40 2001
+++ cfs-1.3.3-new/cfs_nfs.c     Wed Jun  6 00:34:34 2001
@@ -873,7 +873,7 @@
        ne=0;
        prev= &ret.readdirres_u.reply.entries;
        *prev=NULL;
-       bcopy(ap->cookie,&cookie,sizeof(cookie));
+       cookie = ntohl(*(unsigned long*)(ap->cookie));
        eof=TRUE;
        
        key=keyof(h);
@@ -910,7 +910,7 @@
                else if (strcmp(s,"..")==0)     /* parent */
                        entrytab[ne].fileid=fhpid(h);
                else entrytab[ne].fileid=dent->d_fileno;
-               bcopy(&cookie,entrytab[ne].cookie,sizeof(long));
+               *(unsigned long*)entrytab[ne].cookie = htonl(cookie);
                *prev = &entrytab[ne];
                prev = &entrytab[ne].nextentry;
                entrytab[ne].nextentry=NULL;
@@ -1127,7 +1127,7 @@
        ne=0;
        prev= &ret.readdirres_u.reply.entries;
        *prev=NULL;
-       bcopy(ap->cookie,&cookie,sizeof(long));
+       cookie = ntohl(*(unsigned long*)(ap->cookie));
        eof=1;
        
        ret.status=NFS_OK;
@@ -1146,7 +1146,7 @@
                else entrytab[ne].fileid=dent->d_fileno;
                cookie=dent->d_reclen;  /* may not work everywhere */
                *prev = &entrytab[ne];
-               bcopy(&cookie,entrytab[ne].cookie,sizeof(long));
+               *(unsigned long*)entrytab[ne].cookie = htonl(cookie);
                prev = &entrytab[ne].nextentry;
                entrytab[ne].nextentry=NULL;
                ne++;

------------------------------

From: [EMAIL PROTECTED] (Jan Panteltje)
Subject: Re: which library for GUI is best?
Date: Fri, 08 Jun 2001 14:51:25 GMT

On a sunny day (Fri, 08 Jun 2001 01:19:15 +0200) it happened Uwe Bosse
<[EMAIL PROTECTED]> wrote in <[EMAIL PROTECTED]>:

>I want to write applications with a GUI for Linux system.
>There seem to be many C or C++ libraries that provide an access to the
>X-Server
>and functions to open Windows with Scrollbars to present lists and
>buttons and all that 
>stuff. 
>
>I found, for example, the Gimp Toolkit Gtk. (and its C++-Wrapper gtk--)
>Is it worth to spend a lot of time to learn how to use it? 
>Or is there something better? (Something better could be a library, to
>which there exists a
>good tutorial)
>
>Thanks in advance, Uwe.
>
Only thing I could ever get used to was xforms.
Regards
Jan

------------------------------

From: [EMAIL PROTECTED] (David McCaw)
Subject: Re: inexplicable error
Date: 8 Jun 2001 08:15:00 -0700

Aleksandr Morgulis <[EMAIL PROTECTED]> wrote in message 
news:<dSVS6.14496$[EMAIL PROTECTED]>...
> Strange. This code works fine on my system. So you problem could be a 
> memory corruption occuring somewhere before this code gets executed. If the 
> program generated the core file try to load it into gdb.
> 
> AM

If it is some type of memory corruption problem, we here at ParaSoft
supply a tool, Insure++,
that instruments code and automatically finds bugs related to how you
use memory, including
memory corruptions and memory leaks.  If you're interested in trying
it out and seeing what
it can find for you, feel free to email me directly.  For more info,
you can go to:

http://www.parasoft.com/products/insure/index.htm

-David

------------------------------

From: [EMAIL PROTECTED]
Subject: Re: which library for GUI is best?
Date: Fri, 08 Jun 2001 16:21:20 +0100

Uwe Bosse wrote:
> 
> I want to write applications with a GUI for Linux system.
> There seem to be many C or C++ libraries that provide an access to the
> X-Server
> and functions to open Windows with Scrollbars to present lists and
> buttons and all that
> stuff.
> 
> I found, for example, the Gimp Toolkit Gtk. (and its C++-Wrapper gtk--)
> Is it worth to spend a lot of time to learn how to use it?
> Or is there something better? (Something better could be a library, to
> which there exists a
> good tutorial)

When I was looking around last year I looked at various libraries. I
narrowed things down to Qt & GTK+.

I tried GTK+, and variants (VDK etc) and found them a bit flaky on my
Linux box. Also the porting path to Windows didn't seem to have been
sorted.

I tried Qt Free. It works mostly how the documentation describes, ports
to Windows cleanly (not that I have tried), and is easy to use. I
develop in kdevelop and QT Designer, things work well.

-- 
Simon Dales, Publication Software Engineer
"The impossible is easy"
Nuffield Press Ltd., 21 Nuffield Way, Abingdon, Oxford, OX14 1RL,UK
+44-1235-558637

------------------------------

Date: Fri, 08 Jun 2001 17:32:09 +0200
From: Jan Atle Ramsli <[EMAIL PROTECTED]>
Subject: Re: =?iso-8859-1?Q?=EF=20=F7=E9=EE=E4=F9=21=21=21=21=21?=

áÒÔ£Í wrote:
> 
> äÁÒÏ× ×ÓÅÍ!!!!!
> ðÏÄËÉÎÔÅ ÞÔÏ ÎÉÂÕÄØ Ï ÷éîäù!!!
> öÅÌÁÔÅÌØÎÏ ÐÏ ÏÐÔÉÍÉÚÁÃÉÉÉ!!!
Do zdrasdvojet sovjetskij sojus!

------------------------------

From: "Clifton T. Sharp Jr." <[EMAIL PROTECTED]>
Subject: stdout troubles
Date: Fri, 08 Jun 2001 12:58:47 -0500

On May 17 I wrote asking for help on a program I wrote that loses stdout
after a SIGINT. I've made no progress since then.

The other day I started troubleshooting leafnode, which hangs on occasion
for no apparent reason. By adding printf() statements, I've determined
it's hanging on an 'fflush(stdout)'; it executes the printf() preceding,
but never the printf() following, that statement.

When it was my program, I figured it was just a bug I couldn't find. But
I didn't write or modify leafnode (except for the printf statements, which
don't affect the hang).

I figured it might be the kernel; but I've since replaced the 2.2.18 kernel
with 2.2.19, with only the reiserfs patch (which showed zero errors).

Thought about hardware, but I've since replaced the motherboard and the
processor. (From Athlon classic 600 to t-bird 1200.) Same memory, but
memtest likes all my memory. Power supply has the right certifications
for Athlon, no reason to suspect problems.

Thought about X being a problem; but I've since upgraded to 4.0.3, with
a new xterm. Using rxvt instead of xterm changes nothing. Running leafnode
(or my program) outside X changes nothing. (Was running 4.0.1.)

I'm just running out of things to change, and still I have two very
distinct stdout problems in two very different programs. I really, really
need some ideas.

-- 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Cliff Sharp   |  "Speech isn't free when it comes postage-due."           |
|      WA9PDM     |   -- Jim Nitchals, founder, FREE                          |
+-+-+-+-+-+-+-+-+-+- http://www.spamfree.org/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

------------------------------


** FOR YOUR REFERENCE **

The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:

    Internet: [EMAIL PROTECTED]

You can send mail to the entire list by posting to the
comp.os.linux.development.apps newsgroup.

Linux may be obtained via one of these FTP sites:
    ftp.funet.fi                                pub/Linux
    tsx-11.mit.edu                              pub/linux
    sunsite.unc.edu                             pub/Linux

End of Linux-Development-Apps Digest
******************************

Reply via email to