Re: threads question
this works perfectly because I moved MGPMrUpgrade into the same .c file so it would be a static function: structProperty* property; pthread_t threads[NTHREADS]; pthread_create( threads[0], NULL, zzMGPMrUpgrade, property ); When I use MGPMrUpgrade from a shared library the function runs yet property isn't being passed! What do you mean by it not being passed? Does your function receive a NULL value for the parameter instead of the pointer? (Assuming no dirty tricks, the function would by definition always be passed *some* value, though it may be NULL.) Hmmm, should I'll try making property global then passing a copy of it to each thread? I think that will guarantee it stays valid. Since you are asking about makint it global - what is it *now*? It would have to be either global, dynamically allocated, or on the stack. If it's on the stack, things are guaranteed to blow up unless the function in question is guaranteed to not terminate untill all threads are done with the data. What is the property pointer being initialized/set to? If it's dynamically allocated you should not have a problem. And I don't see how static vs. dynamic linking of libraries should matter, but perhaps I am overlooking something. -- / Peter Schuller, InfiDyne Technologies HB PGP userID: 0xE9758B7D or 'Peter Schuller [EMAIL PROTECTED]' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: threads question
On Wednesday 16 March 2005 01:40 pm, you wrote:
this works perfectly because I moved MGPMrUpgrade into
the same .c file so it would be a static function:
structProperty* property;
pthread_t threads[NTHREADS];
pthread_create( threads[0], NULL, zzMGPMrUpgrade, property );
When I use MGPMrUpgrade from a shared library the function runs
yet property isn't being passed!
What do you mean by it not being passed? Does your function receive a
NULL value for the parameter instead of the pointer? (Assuming no
dirty tricks, the function would by definition always be passed
*some* value, though it may be NULL.)
I finally figured out what I was doing wrong, it was my lack of
understanding threads. here is what I was doing:
int main()
{
int(*fpt)(structProperty*);
fpt= ThreadFunct;
runFunc( fpt );
}
int Funct( int(*fpt)(structProperty*) )
{
pthread_t threads[NTHREADS];
structProperty* property
pthread_create(
threads[0],
NULL,
int(*fpt)(structProperty*)ThreadFunct,
(void*)property );
}
Thats just a rough outline, anyways property was going out of scope
while the thread was running, just as Zera and Daniel warned me about.
I just moved the declaration into main and switched tool kits to motif
from GTK and all is well.
Basically I could not pass a function pointer as a call back with
paramaters from a GTK button through to actually running the function.
That is why I moved the declaration of property down a level in the
first place, didn't occur to me how vital scope is when using threads
though.
Switched to motif and everything passes flawlessly. I wish GTK had
either better docs or wasn't broken, not sure what the problem is
there, probably my lack of understanding again but I don't care, motif
will work for what I need to do.
If it wasn't for Zera and Daniel's questions I would have never figured
this out!
Hmmm, should I'll try making property global then passing a copy
of it to each thread? I think that will guarantee it stays valid.
Since you are asking about makint it global - what is it *now*? It
would have to be either global, dynamically allocated, or on the
stack. If it's on the stack, things are guaranteed to blow up unless
the function in question is guaranteed to not terminate untill all
threads are done with the data. What is the property pointer being
initialized/set to?
If it's dynamically allocated you should not have a problem.
And I don't see how static vs. dynamic linking of libraries should
matter, but perhaps I am overlooking something.
I don't get that either, should not have worked either way as far as I
can tell.
-Mike
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: threads question
On Monday 14 March 2005 08:57 pm, Daniel Eischen wrote: On Mon, 14 Mar 2005, Michael C. Shultz wrote: Hi, I've just reached a point in a program I'm writing where I'd like to do threading. When I try to start a thread like this: pthread_create(thread, attr, MGPMrUpgrade, property ); property You should compile with -Wall and get rid of any warnings. where property is a structure of many variables it doesn't get passed to the function. If I do this: pthread_create(thread, attr, MGPMrUpgrade( property ), NULL ); That looks like it will actuall call MGPMrUpgrade() and use its return value as the function pointer. It works, but just seems wrong. Can anyone point me to a source file, preferably in /usr/src somewhere that passes a structure to a function being run as a thread so I may study the proper way to do this? src/lib/libpthread/test/sem_d.c src/lib/libpthread/test/mutex_d.c src/lib/libpthread/test/sigwait_d.c I'd suggest getting Butenhof's Programming with POSIX Threads book. Daniel, sorry to bother you again but I ran into something that is either a bug or I am missing a vital piece of information somewhere. Here is the situation: this works perfectly because I moved MGPMrUpgrade into the same .c file so it would be a static function: structProperty* property; pthread_t threads[NTHREADS]; pthread_create( threads[0], NULL, zzMGPMrUpgrade, property ); When I use MGPMrUpgrade from a shared library the function runs yet property isn't being passed! I remember from assembly days that there were some stack tricks to be done when making calls to a shared library in order to pass the parameters, I forget what they are (been ages since I did assembly programming) but anyways it seems like with gcc passing the args through the stack to a function in a shared library isn't being handled correctly. Am I missing something obvious? -Mike ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: threads question
On Tue, 15 Mar 2005, Michael C. Shultz wrote: Daniel, sorry to bother you again but I ran into something that is either a bug or I am missing a vital piece of information somewhere. Here is the situation: this works perfectly because I moved MGPMrUpgrade into the same .c file so it would be a static function: structProperty* property; pthread_t threads[NTHREADS]; pthread_create( threads[0], NULL, zzMGPMrUpgrade, property ); When I use MGPMrUpgrade from a shared library the function runs yet property isn't being passed! I remember from assembly days that there were some stack tricks to be done when making calls to a shared library in order to pass the parameters, I forget what they are (been ages since I did assembly programming) but anyways it seems like with gcc passing the args through the stack to a function in a shared library isn't being handled correctly. Am I missing something obvious? I don't know. You have to be sure that whatever property points to stays valid for the life of the thread (or at least as long as it is used). -- DE ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: threads question
On Tuesday 15 March 2005 10:19 am, Daniel Eischen wrote: On Tue, 15 Mar 2005, Michael C. Shultz wrote: Daniel, sorry to bother you again but I ran into something that is either a bug or I am missing a vital piece of information somewhere. Here is the situation: this works perfectly because I moved MGPMrUpgrade into the same .c file so it would be a static function: structProperty* property; pthread_t threads[NTHREADS]; pthread_create( threads[0], NULL, zzMGPMrUpgrade, property ); When I use MGPMrUpgrade from a shared library the function runs yet property isn't being passed! I remember from assembly days that there were some stack tricks to be done when making calls to a shared library in order to pass the parameters, I forget what they are (been ages since I did assembly programming) but anyways it seems like with gcc passing the args through the stack to a function in a shared library isn't being handled correctly. Am I missing something obvious? I don't know. You have to be sure that whatever property points to stays valid for the life of the thread (or at least as long as it is used). I have to reply to you through freebsd-hackers@freebsd.org because your blocking verizon's smtp. I just converted everything to static libraries and now pthread_create is working just fine. The answer is probably something like what you just said, scope being lost when making the call to a shared library. Why is it ok going to a static library but not a shared though? In a few days, when there is time, I will write an assembly routine with nasm to use pthread_create and pass my structProperty argument to a shared library with it, this way I can see just exactly what is being passed through the stack. Then hopefully I can find some C/assembly guru who can look at it and teach me how to do it with C. Messing with and examining stacks in C is way beyond my present abilities. (I'm a C newbie) -Mike ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: threads question
On Tue, 15 Mar 2005, Michael C. Shultz wrote: [cut] The answer is probably something like what you just said, scope being lost when making the call to a shared library. Why is it ok going to a static library but not a shared though? There is probably a race condition, so your code will work *some* of the time unless you prevent the race condition. I don't have an answer to your question, but I don't think it is a valid question. The scope of *priority can remain valid or invalid for random reasons and thus may work some of the time, but the only way to guarantee that it works all the time is to eliminate the race condition by making sure that *property is valid though the life of the thread. -Zera ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: threads question
On Tuesday 15 March 2005 12:02 pm, you wrote: On Tue, 15 Mar 2005, Michael C. Shultz wrote: [cut] The answer is probably something like what you just said, scope being lost when making the call to a shared library. Why is it ok going to a static library but not a shared though? There is probably a race condition, so your code will work *some* of the time unless you prevent the race condition. I don't have an answer to your question, but I don't think it is a valid question. The scope of *priority can remain valid or invalid for random reasons and thus may work some of the time, but the only way to guarantee that it works all the time is to eliminate the race condition by making sure that *property is valid though the life of the thread. -Zera Hmmm, should I'll try making property global then passing a copy of it to each thread? I think that will guarantee it stays valid. -Mike ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
threads question
Hi, I've just reached a point in a program I'm writing where I'd like to do threading. When I try to start a thread like this: pthread_create(thread, attr, MGPMrUpgrade, property ); where property is a structure of many variables it doesn't get passed to the function. If I do this: pthread_create(thread, attr, MGPMrUpgrade( property ), NULL ); It works, but just seems wrong. Can anyone point me to a source file, preferably in /usr/src somewhere that passes a structure to a function being run as a thread so I may study the proper way to do this? Thank you. -Mike ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: threads question
On Mon, 14 Mar 2005, Michael C. Shultz wrote:
Hi, I've just reached a point in a program I'm writing where I'd like to
do threading.
When I try to start a thread like this:
pthread_create(thread, attr, MGPMrUpgrade, property );
property
You should compile with -Wall and get rid of any warnings.
where property is a structure of many variables it doesn't get passed
to the function. If I do this:
pthread_create(thread, attr, MGPMrUpgrade( property ), NULL );
That looks like it will actuall call MGPMrUpgrade() and use its
return value as the function pointer.
It works, but just seems wrong.
Can anyone point me to a source file, preferably in /usr/src somewhere
that passes a structure to a function being run as a thread so I may
study the proper way to do this?
src/lib/libpthread/test/sem_d.c
src/lib/libpthread/test/mutex_d.c
src/lib/libpthread/test/sigwait_d.c
I'd suggest getting Butenhof's Programming with POSIX Threads book.
--
DE
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: threads question
On Monday 14 March 2005 08:57 pm, Daniel Eischen wrote: On Mon, 14 Mar 2005, Michael C. Shultz wrote: Hi, I've just reached a point in a program I'm writing where I'd like to do threading. When I try to start a thread like this: pthread_create(thread, attr, MGPMrUpgrade, property ); property You should compile with -Wall and get rid of any warnings. where property is a structure of many variables it doesn't get passed to the function. If I do this: pthread_create(thread, attr, MGPMrUpgrade( property ), NULL ); That looks like it will actuall call MGPMrUpgrade() and use its return value as the function pointer. It works, but just seems wrong. Can anyone point me to a source file, preferably in /usr/src somewhere that passes a structure to a function being run as a thread so I may study the proper way to do this? src/lib/libpthread/test/sem_d.c src/lib/libpthread/test/mutex_d.c src/lib/libpthread/test/sigwait_d.c Great! I'd suggest getting Butenhof's Programming with POSIX Threads book. I did a google on Programming with POSIX Threads and this site popped up first. I remember this guy's stuff from way back when on signals I think, it was great for a beginner so maybe this one is worth looking at too. http://users.actcom.co.il/~choo/lupg/tutorials/multi-thread/multi-thread.html; I found the book at Amazon, thanks for the tip! Many thanks! -Mike ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
POSIX threads question
HI everybody. I'm having a problem writing a multi-threaded application. As I understand from the mans, calls to read and write are synchronized through file-locks. Having looked through the source for libc_r I noticed that calls to printf and fprintf are also synchronized. The question is - why I am still having a problem calling fprintf(stderr, ... from multiple threads, the output is simply not written until I make a socond or a third call to fprintf. I have disabled buffering for stderr with setvbuf. Thank you in advance. --- Sent by InfoArt iMail http://www.infoart.ru; http://www.stars.ru To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: POSIX threads question
Files are block buffered not line buffered. Switch on hot piping (sorry, don't know how to), or wait until you have written 64kb, of flush more often. Nick On Tue, 20 Jul 1999, Andrei Iltchenko wrote: Hi there, I have written a multithreaded application. In which, I have redirected stdin, stdout and stderr to some files. Does anybody know why if I make a call to fprintf family of functions, I get nothing in the output files, until I call fflush? Thank you in advance. --- Sent by InfoArt iMail http://www.infoart.ru; http://www.stars.ru To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: POSIX threads question
man 3 setvbuf - ad Hi there, I have written a multithreaded application. In which, I have redirected stdin, stdout and stderr to some files. Does anybody know why if I make a call to fprintf family of functions, I get nothing in the output files, until I call fflush? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
POSIX threads question
Hi there, I have written a multithreaded application. In which, I have redirected stdin, stdout and stderr to some files. Does anybody know why if I make a call to fprintf family of functions, I get nothing in the output files, until I call fflush? Thank you in advance. --- Sent by InfoArt iMail http://www.infoart.ru; http://www.stars.ru To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: POSIX threads question
Files are block buffered not line buffered. Switch on hot piping (sorry, don't know how to), or wait until you have written 64kb, of flush more often. Nick On Tue, 20 Jul 1999, Andrei Iltchenko wrote: Hi there, I have written a multithreaded application. In which, I have redirected stdin, stdout and stderr to some files. Does anybody know why if I make a call to fprintf family of functions, I get nothing in the output files, until I call fflush? Thank you in advance. --- Sent by InfoArt iMail http://www.infoart.ru; http://www.stars.ru To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: POSIX threads question
man 3 setvbuf - ad Hi there, I have written a multithreaded application. In which, I have redirected stdin, stdout and stderr to some files. Does anybody know why if I make a call to fprintf family of functions, I get nothing in the output files, until I call fflush? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
