Linux-Development-Apps Digest #412, Volume #7 Thu, 17 May 01 19:13:07 EDT
Contents:
Re: A linuxthreads C++ object question (Daniel Barron)
Re: A linuxthreads C++ object question (Daniel Barron)
Re: A linuxthreads C++ object question (Daniel Barron)
Re: A linuxthreads C++ object question (Daniel Barron)
Re: timeout for non blocking sockets (Daniel Barron)
Re: timeout for non blocking sockets (Daniel Barron)
Re: Obtaining the full path name of a file? (Juergen Heinzl)
Re: A linuxthreads C++ object question ("Neil Butterworth")
Re: A linuxthreads C++ object question ("Neil Butterworth")
Re: Obtaining the full path name of a file? (Timur Tabi)
Re: SIGSEGV is not blocking (Eric P. McCoy)
Re: Obtaining the full path name of a file? (Juergen Heinzl)
Re: SIGSEGV is not blocking (David Schwartz)
Re: HELP! Memory leaks!!!
Re: Can I use aio_read() for UDP sockets?
Re: A linuxthreads C++ object question (Jim Cochrane)
----------------------------------------------------------------------------
From: Daniel Barron <[EMAIL PROTECTED]>
Subject: Re: A linuxthreads C++ object question
Date: Thu, 17 May 2001 21:25:35 +0100
In message <9dvaks$[EMAIL PROTECTED]>
[EMAIL PROTECTED] (Jim Cochrane) wrote:
[snip]
> >Eg this pseudo code:
> >
> >main() {
> >createthread(pointer to somecode(1)); //thread a
> >createthread(pointer to somecode(2)); //thread b
> >}
> >somecode(i) {
> >objectblah o;
> >o.somevariable = i;
> >}
> >
> >Does the thread a know anything about or modify o in thread b?
> >
>
> Using multiple threads does not change the the workings of basic mechanisms
> in C and C++ like the stack and the heap. The code of this simple program
> will behave the same whether or not multiple threads are used. In
> somecode, you are creating an object on the stack, as a local variable.
> Each time that function is called, with or without threading, a new
> instance will be created and then destroyed when somecode returns - there
> is no data sharing set up in this code.
I see, that makes sense.
But just to be clear:
main() {
createthread(pointer to somecode(1)); //thread a
createthread(pointer to somecode(2)); //thread b
}
somecode(i) {
int j;
j = i;
}
This /would/ cause a race condition, yes?
[snip]
--
Daniel Barron - use [at jadeb.com] for personal replys.
------------------------------
From: Daniel Barron <[EMAIL PROTECTED]>
Subject: Re: A linuxthreads C++ object question
Date: Thu, 17 May 2001 21:31:03 +0100
In message <[EMAIL PROTECTED]>
[EMAIL PROTECTED] (Kaz Kylheku) wrote:
[snip]
> that some kinds of C++ objects contain data which are not directly visible
> to the programmer, such as vtable pointers, type informations and so on.
> Such fields are set up as an object is constructed. The best rule to follow
> is to avoid accessing an object from multiple threads until it is fully
> constructed, and after just before its destruction has begun. This
> rule is required because there is no satisfactory way to protect this
> invisible data against concurrent access, other than total abstinence.
But this is utterly ludicrus! Multithreaded apps must have loads and loads
of mutexes for every object creation:
lock objectmutex;
object myobject;
unlock objectmutex;
Talk about asking for deadlock! Is this really true? I can't believe its
sooo ficle or messy!
[snip]
> of one object from multiple threads. Then, that object's non-static data
> members must be properly guarded against concurrent access.
object data is non-static by default right?
--
Daniel Barron - use [at jadeb.com] for personal replys.
------------------------------
From: Daniel Barron <[EMAIL PROTECTED]>
Subject: Re: A linuxthreads C++ object question
Date: Thu, 17 May 2001 21:35:24 +0100
In message <[EMAIL PROTECTED]>
[EMAIL PROTECTED] (David Konerding) wrote:
[snip]
>
> With your own code, if two threads both instantiate an object of a
> particular type of class, it is possible to have a race condition IF the
> two instances contain a shared variable. For example, if you declare a
> variable static in the class definition, then that variable will be shared
> by all instances and access by either thread will be touching the same part
> of memory. The non-static variables are allocated on the individual stacks
> of the two threads, and any access to allocated heap memory goes through
> new/malloc, which is thread-safe.
This sounds counter to another person:
> that some kinds of C++ objects contain data which are not directly visible
> to the programmer, such as vtable pointers, type informations and so on.
> Such fields are set up as an object is constructed. The best rule to follow
> is to avoid accessing an object from multiple threads until it is fully
> constructed, and after just before its destruction has begun. This rule is
> required because there is no satisfactory way to protect this invisible
> data against concurrent access, other than total abstinence.
You say IF, he says ALWAYS. Which is correct?
--
Daniel Barron - use [at jadeb.com] for personal replys.
------------------------------
From: Daniel Barron <[EMAIL PROTECTED]>
Subject: Re: A linuxthreads C++ object question
Date: Thu, 17 May 2001 21:37:19 +0100
In message <[EMAIL PROTECTED]>
"Neil Butterworth" <[EMAIL PROTECTED]> wrote:
[snip]
> This shows that STLport does _not_ provide the level of safety that you
> claim it does.
>
> > Also, from experience, I am using a threaded application which makes
> > heavy use of C++ (and the standard library) in both the main thread and
> > in other threads.
>
> Me too. I had a middle tier CORBA server which used multiple threads
> waiting on semaphore to pull requests off a queue. The app would work
> perfectly for weeks at a time and then crash randomly because multiple
> threads were accessing the same container. I had to provide a mutex to cure
> it.
Very interesting. How did you work out where the problem was?
--
Daniel Barron - use [at jadeb.com] for personal replys.
------------------------------
From: Daniel Barron <[EMAIL PROTECTED]>
Subject: Re: timeout for non blocking sockets
Date: Thu, 17 May 2001 21:57:35 +0100
In message <mmRM6.85325$[EMAIL PROTECTED]>
"TdC" <no#[EMAIL PROTECTED]#spam> wrote:
[snip]
>
> connect(fd, (struct sockaddr *)&server,sizeof(struct sockaddr));
Try this:
if (connect(fd, (struct sockaddr *)&server,sizeof(struct sockaddr))) {
die("connect");
}
To see if there is a problem connecting.
>From my limited understanding a non-blocking connect in this way would
return immediately with sucess or failure. My linux programming book only
meantions select() for use with accept(), not connect().
However this seems silly as there /must/ be a way to do it with a timeout.
>
> if (select(FD_SETSIZE, NULL, &MySet, NULL, &Interval) != 1)
> {
> printf("timeout?\n");
> break;
> }
I would suggest '< 1' rather than '!= 1' as the test also.
--
Daniel Barron - use [at jadeb.com] for personal replys.
------------------------------
From: Daniel Barron <[EMAIL PROTECTED]>
Subject: Re: timeout for non blocking sockets
Date: Thu, 17 May 2001 21:57:48 +0100
In message <JFSM6.85436$[EMAIL PROTECTED]>
"TdC" <no#[EMAIL PROTECTED]#spam> wrote:
>
> "Kaz Kylheku" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > On Thu, 17 May 2001 14:37:06 GMT, TdC <no#[EMAIL PROTECTED]#spam> wrote:
> > >i'm trying to create a time for my connection
> > >so when it doesn't connect for 3 seconds, it should give up
> > >here is my code
> >
> > > /*set the timeout */
> > > timeval Interval;
> > > Interval.tv_sec = 3;
> >
> > You don't suppose that struct timeval has other members
> > that need to be initialized?
>
> um yes
> Interval.tv_usec = 3000;
>
> but it doesn't work with that added too
No, you'd only need
Interval.tv_usec = 0;
and
Interval.tv_sec = 3;
So in what way does it fail to work?
--
Daniel Barron - use [at jadeb.com] for personal replys.
------------------------------
From: [EMAIL PROTECTED] (Juergen Heinzl)
Subject: Re: Obtaining the full path name of a file?
Date: Thu, 17 May 2001 21:35:48 GMT
In article <[EMAIL PROTECTED]>, Timur Tabi wrote:
>I have an application that takes a list of filenames on the
>command-line. How do I expand these filenames into their full path
>name?
>
>For example, assume the current directory is /usr/local/bin. Then,
>
>ssh -> /usr/local/bin/ssh
[-]
ln /usr/local/bin/ssh /usr/local/sbin/ssh -- which path is the
right one ?
... or ...
ln -s /usr/local/nfs/bin /usr/local/bin -- which path is the
right one ?
So it depends quite a lot, but if you only need to consider
what's in your PATH, then ...
* use (l)stat()
* if you want to follow symbolic links, then use readlink()
and mind a symbolic links link name may be a symbolic link
itself again.
* if you want to take hard links into account, then
you have to search for all files with the same inode
in the current file system and hard links cannot cross
devices which makes life a bit easier here.
Ta',
Juergen
--
\ Real name : Juergen Heinzl \ no flames /
\ EMail Private : [EMAIL PROTECTED] \ send money instead /
------------------------------
From: "Neil Butterworth" <[EMAIL PROTECTED]>
Subject: Re: A linuxthreads C++ object question
Date: Thu, 17 May 2001 22:35:57 +0100
"Daniel Barron" <[EMAIL PROTECTED]> wrote
in message news:[EMAIL PROTECTED]...
> In message <[EMAIL PROTECTED]>
> "Neil Butterworth" <[EMAIL PROTECTED]> wrote:
> [snip]
> > This shows that STLport does _not_ provide the level of safety that you
> > claim it does.
> >
> > > Also, from experience, I am using a threaded application which makes
> > > heavy use of C++ (and the standard library) in both the main thread
and
> > > in other threads.
> >
> > Me too. I had a middle tier CORBA server which used multiple threads
> > waiting on semaphore to pull requests off a queue. The app would work
> > perfectly for weeks at a time and then crash randomly because multiple
> > threads were accessing the same container. I had to provide a mutex to
cure
> > it.
>
> Very interesting. How did you work out where the problem was?
With enormous difficulty - it took about two months. I should say that this
server was providing data for a real-time equity trading system - when it
crashed the traders were not happy bunnies! However, close reading of the
documentation made me realise that the "thread-safety" guarantee of the
library was not quite what I thought it was Once I realised what the
library guaranteed, and what I had to do on my side, things got fixed pretty
quickly.
Bottom line: RTFM.
NeilB
------------------------------
From: "Neil Butterworth" <[EMAIL PROTECTED]>
Subject: Re: A linuxthreads C++ object question
Date: Thu, 17 May 2001 22:40:54 +0100
"Daniel Barron" <[EMAIL PROTECTED]> wrote
in message news:[EMAIL PROTECTED]...
> In message <[EMAIL PROTECTED]>
> [EMAIL PROTECTED] (Kaz Kylheku) wrote:
> [snip]
> > that some kinds of C++ objects contain data which are not directly
visible
> > to the programmer, such as vtable pointers, type informations and so on.
> > Such fields are set up as an object is constructed. The best rule to
follow
> > is to avoid accessing an object from multiple threads until it is fully
> > constructed, and after just before its destruction has begun. This
> > rule is required because there is no satisfactory way to protect this
> > invisible data against concurrent access, other than total abstinence.
>
> But this is utterly ludicrus! Multithreaded apps must have loads and
loads
> of mutexes for every object creation:
Any given object can only be created by one thread, and you can't pass a
reference or pointer to it off to another thread until all constructors have
completed (unless you are mad enough to spin off threads in a constructor) -
so there is no contention.
>
> lock objectmutex;
> object myobject;
> unlock objectmutex;
>
> Talk about asking for deadlock! Is this really true? I can't believe its
> sooo ficle or messy!
No, it isn't, except in pathological situations.
NeilB
------------------------------
From: Timur Tabi <[EMAIL PROTECTED]>
Subject: Re: Obtaining the full path name of a file?
Date: Thu, 17 May 2001 16:49:04 -0500
Juergen Heinzl wrote:
>
> In article <[EMAIL PROTECTED]>, Timur Tabi wrote:
> >I have an application that takes a list of filenames on the
> >command-line. How do I expand these filenames into their full path
> >name?
> >
> >For example, assume the current directory is /usr/local/bin. Then,
> >
> >ssh -> /usr/local/bin/ssh
> [-]
> ln /usr/local/bin/ssh /usr/local/sbin/ssh -- which path is the
> right one ?
Well, since I'm in /usr/local/bin, then 'ssh' translates to
/usr/local/bin/ssh. Did I not make that clear? Where does
/usr/local/sbin come from?
> ln -s /usr/local/nfs/bin /usr/local/bin -- which path is the
> right one ?
It doesn't matter. If /usr/local/bin is aliased to /usr/local/nfs/bin,
then /usr/local/bin/ssh will still be correct.
> So it depends quite a lot, but if you only need to consider
> what's in your PATH, then ...
That PATH variable does not come into play at all. I'll I'm trying to
do is translate relative path names into absolute path names.
--
Timur Tabi
Remove "nospam_" from email address before sending reply
Interactive Silicon - http://www.interactivesi.com
------------------------------
Crossposted-To: comp.os.linux.development.system,comp.programming.threads
Subject: Re: SIGSEGV is not blocking
From: [EMAIL PROTECTED] (Eric P. McCoy)
Date: 17 May 2001 18:02:20 -0400
"Michael J. Saletnik" <[EMAIL PROTECTED]> writes:
> > Well, the kernel has no alternative. It has to do something. You told it
> > not to send the SEGV, so _what_ do you expect it to do?
> My expectations all along have been tailored specifically to the
> interpretation of POSIX and the documentation provided in the Linux
> man pages, relative to the original poster's question of "it does
> something different under AIX". These talk about behavior being
> undefined after ignoring a SIGSEGV not generated by kill() or raise().
I'm not sure how you mean this, so I won't comment. (But will leave
it in if you want to clarify.)
[...]
> The answers to these were not mentioned *anywhere* that I can find
> (heck, the man page for signal(7) on my RH6.2 2.2.19 system reads
> "Linux 1.3.88 April 14, 1996") and that was my issue.
If that man page describes the POSIX-standard behavior, and Linux has
maintained POSIX compatability in this regard since then, there's no
reason to update it.
> > The CPU does not
> > advance the instruction pointer past the instruction that faulted,
> Of course! [slaps self in head] The scary thing is that I knew this,
> because otherwise such things as page faults wouldn't work.
Don't feel too bad. Traps, which are also exceptions, do advance EIP
on IA32 CPUs. But there are only 2.5 traps which the CPU can raise.
--
Eric McCoy <[EMAIL PROTECTED]>
"Knowing that a lot of people across the world with Geocities sites
absolutely despise me is about the only thing that can add a positive
spin to this situation." - Something Awful, 1/11/2001
------------------------------
From: [EMAIL PROTECTED] (Juergen Heinzl)
Subject: Re: Obtaining the full path name of a file?
Date: Thu, 17 May 2001 22:24:41 GMT
In article <[EMAIL PROTECTED]>, Timur Tabi wrote:
>Juergen Heinzl wrote:
>>
>> In article <[EMAIL PROTECTED]>, Timur Tabi wrote:
>> >I have an application that takes a list of filenames on the
>> >command-line. How do I expand these filenames into their full path
>> >name?
>> >
>> >For example, assume the current directory is /usr/local/bin. Then,
>> >
>> >ssh -> /usr/local/bin/ssh
>> [-]
>> ln /usr/local/bin/ssh /usr/local/sbin/ssh -- which path is the
>> right one ?
>
>Well, since I'm in /usr/local/bin, then 'ssh' translates to
>/usr/local/bin/ssh. Did I not make that clear? Where does
>/usr/local/sbin come from?
[-]
If I / you / the cat created a link for instance ? Your system
or configuration is not representative after all and you need
to state what the results are going to be if, that's all.
>> ln -s /usr/local/nfs/bin /usr/local/bin -- which path is the
>> right one ?
>
>It doesn't matter. If /usr/local/bin is aliased to /usr/local/nfs/bin,
>then /usr/local/bin/ssh will still be correct.
[-]
Yup, just to clarify what you define as "correct".
>> So it depends quite a lot, but if you only need to consider
>> what's in your PATH, then ...
>
>That PATH variable does not come into play at all. I'll I'm trying to
>do is translate relative path names into absolute path names.
[-]
Yup, okay, then dirname(3) would give you the path and you'd
follow the directory and once there getcwd() is going to do
the job, easy.
You've to do it yourself, though as there's no system call or
libc function like resolve_path(), no and dirname() only isolates
the path part, say ../me/Mail becomes ../me and not /home/me.
Ta',
Juergen
--
\ Real name : Juergen Heinzl \ no flames /
\ EMail Private : [EMAIL PROTECTED] \ send money instead /
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.system,comp.programming.threads
Subject: Re: SIGSEGV is not blocking
Date: Thu, 17 May 2001 15:43:54 -0700
"Michael J. Saletnik" wrote:
> which was meant to question if it was the kernel delivering the signal
> anyway, or the kernel or some other layer clearing the block and
> refaulting.
The kernel is the only code that could possibly have done it. The
kernel found itself handling a page fault that was a segmentation
violation and found nothing sane it could do, so it killed the process.
> Of course! [slaps self in head] The scary thing is that I knew this,
> because otherwise such things as page faults wouldn't work. I got so
> wrapped up in "but it doesn't *say* that anywhere" that I totally
> blitzed on this fact. I don't know why I presumed the process could
> continue in the presence of a cpu-raised segfault; I think I was
> considering a point about blocking in the presence of raise(SIGSEGV);
> and got sidetracked.
Right. Only the kernel can determine that the page fault is a fatal
one. And all it can do is continue the process where it left off or
change it to go somewhere else.
DS
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: HELP! Memory leaks!!!
Date: Thu, 17 May 2001 23:06:45 -0000
In article <K0zM6.236567$[EMAIL PROTECTED]>,
Jiva DeVoe <[EMAIL PROTECTED]> wrote:
>It seems to me, by deleting bar,
>it should go DOWN in memory usage. Shouldn't it?
Why should it? Memory isn't always returned to the OS when you
delete an object. The space is just put on a free list for later
use.
--
http://www.spinics.net/linux
------------------------------
From: [EMAIL PROTECTED] ()
Subject: Re: Can I use aio_read() for UDP sockets?
Date: Thu, 17 May 2001 23:08:37 -0000
In article <9ds4l2$dpt$[EMAIL PROTECTED]>,
Roger Tragin <[EMAIL PROTECTED]> wrote:
>Under Windoze I am using WSARecvFrom() to read datagrams from a UDP socket
>asynchronously. Is there an equivalent under Linux?
How many times are you going to ask this? You set the O_ASYNC option.
--
http://www.spinics.net/linux/
------------------------------
From: [EMAIL PROTECTED] (Jim Cochrane)
Subject: Re: A linuxthreads C++ object question
Date: 17 May 2001 17:08:38 -0600
In article <[EMAIL PROTECTED]>,
Daniel Barron <[EMAIL PROTECTED]> wrote:
>In message <9dvaks$[EMAIL PROTECTED]>
> [EMAIL PROTECTED] (Jim Cochrane) wrote:
>[snip]
>> >Eg this pseudo code:
>> >
>> >main() {
>> >createthread(pointer to somecode(1)); //thread a
>> >createthread(pointer to somecode(2)); //thread b
>> >}
>> >somecode(i) {
>> >objectblah o;
>> >o.somevariable = i;
>> >}
>> >
>> >Does the thread a know anything about or modify o in thread b?
>> >
>>
>> Using multiple threads does not change the the workings of basic mechanisms
>> in C and C++ like the stack and the heap. The code of this simple program
>> will behave the same whether or not multiple threads are used. In
>> somecode, you are creating an object on the stack, as a local variable.
>> Each time that function is called, with or without threading, a new
>> instance will be created and then destroyed when somecode returns - there
>> is no data sharing set up in this code.
>
>I see, that makes sense.
>
>But just to be clear:
>
>main() {
> createthread(pointer to somecode(1)); //thread a
> createthread(pointer to somecode(2)); //thread b
>}
>somecode(i) {
> int j;
> j = i;
>}
>
>This /would/ cause a race condition, yes?
No. j is, again, a local variable - on the stack. In thread a j will
be set to 1, in thread b, to 2. The value of i is copied into j and j
is not shared. There is no data sharing so there is no possibility of
a race condition. You have to explicitly share data to have a
potential race condition. For example,
main() {
SomeClass* sc = new SomeClass();
createthread(pointer to somecode(sc)); //thread a
createthread(pointer to somecode(sc)); //thread b
}
somecode(SomeClass* x) {
x->method_that_changes_object_s_state();
}
I've extended your pseudocode to indicate passing a pointer to an object to
the thread routine somecode. (I've not used POSIX threads for a good
while, so this may not be precisely how an address would be shared, but
hopefully it's close enough to get the point across.) The sc address (that
holds a SomeClass instance) is shared by the two threads because they both
pass that address to somecode. So when somecode calls:
x->method_that_changes_object_s_state();
It is changing the state of that same address, in both thread a and thread
b. If method_that_changes_object_s_state is thread safe, you have shared data
but no race condition. However, if method_that_changes_object_s_state is not
thread safe, you may have a race condition.
This is what I mean by explicitly sharing data - you are explicitly passing
the same address to be used by both threads. (Explicit does not
necessarily mean obvious - you might share global data (which is explicit)
without realizing it because it's not obvious when you read the code.
(It's best to try to avoid writing code like that.))
Hope this makes things clearer.
--
Jim Cochrane
[EMAIL PROTECTED]
------------------------------
** 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
******************************
