Hi,
I was trying to put in some code in a file . Make it a shared object (.so) with
PIC and am trying to generate some Relative Relocations
(R_XXX_RELATIVE) type. For verifying the same, I take the Elf Dump of the
generated object (.so) file using 'elfdump'.
Can any one please suggest me a C
Hi,
I was trying to put in some code in a file . Make it a shared object (.so)
with PIC and am trying to generate some Relative Relocations
(R_XXX_RELATIVE) type. For verifying the same, I take the Elf Dump of the
generated object (.so) file using 'elfdump'.
Can you please suggest me a C code con
On Thu, 22 Feb 2007, Tsutomu Enokida wrote:
I wanted to check using a simple program that it is possible to call thread
hot programs from
nonthreaded programs using dlopen.
The Sub-program needs to be linked with libpthread.so, but don't need to be
compiled with
-D_POSIX_C_SOURCE=. Is my und
Haris wrote:
Hi -
Concerning the MMU's primary context register. I know that this represents the
active context on the processor and is used to find mappings in the TLB. My
understanding is that context should be different for each OS process. However,
in Ultrasparc for instance, the context
I wanted to check using a simple program that it is possible to call thread hot
programs from
nonthreaded programs using dlopen.
The Sub-program needs to be linked with libpthread.so, but don't need to be
compiled with
-D_POSIX_C_SOURCE=. Is my understanding right ?
Sent: Wednesday, Februar
Hi -
Concerning the MMU's primary context register. I know that this represents the
active context on the processor and is used to find mappings in the TLB. My
understanding is that context should be different for each OS process. However,
in Ultrasparc for instance, the context is 13bits which
[EMAIL PROTECTED] wrote:
>
> >> For good reasons, you're
> >> putting the libraries with the other libraries and at some point, it's
> >> not clear if keeping the files which don't really serve a purpose as
> >> documentation (at least for OpenSolaris.) Anyway, this is something
> >> for you to w
On Wed, Feb 21, 2007 at 09:44:11AM -0500, James Carlson wrote:
> > This is bad. Is there no function to define that signals should be
> > send to all threads for async signals?
>
> You don't (and can't) send signals to threads. You send them to
> processes.
Mike's already made this point, but it
>
> Yes, UltraSPARC-IV as well as "OPL" (Multi-core in the first instance,
> multithreaded/multi-core in the second)
>
"OPL" is a platfrom code name. The CPU name is SPARC64-VI and it has two cores
with two threads each or 4 cpuid per chip (per die).
___
On Wed, 21 Feb 2007 15:04:57 -0500 James Carlson wrote:
> I think that's still missing the point.
> This project is integrating ksh93 into ON. Once that's done, there's
> no way that the ON source will be used to build a binary for some
> other release. Having Solaris-versioning-dependent objec
On Tue, 20 Feb 2007, Dan Price wrote:
Hi folks, I'd like to start codereview for the following wad:
PSARC/2007/045 I2O EOL and EOF
4863632 Hey Hey! Ho Ho! I2O Has Got to Go!
Codereview materials and pointers to the ARC case are posted at:
http://cr.grommit.com/~dp/i2o-del
All relevant
On Wed 21 Feb 2007 at 11:15AM, Stephen Hahn wrote:
> * [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2007-02-21 10:53]:
> >
> > > The way we were hoping to do this was to have "wildcard" projects, so
> > > that each user would have a project synthesized automatically upon
> > > login. Then all the pr
James Carlson wrote:
> Glenn Fowler writes:
[snip]
> > now there may be some narrow path of cc/ccs flags/executables && uname -r
> > matching
> > that I could set up to make compatible binaries for all solaris
> > but even then am I crippling later releases for the sake of compatibility
> > with
James Carlson wrote:
> Glenn Fowler writes:
> > > However, if the ATT code already expects this to be "11" for a SunOS
> > > "5.11" version, then I'm fine with what you have now. If you could
> > > pass upstream the feedback, though, that this could break if the minor
> > > part ever reverts to "0
Glenn Fowler writes:
> ksh93s built on
> SunOS hostname 5.8 Generic_108528-26 sun4u sparc SUNW,Sun-Fire-15000
> and run on
> SunOS hostname 5.6 Generic_105181-33 sun4u sparc SUNW,Ultra-2
That cannot be supported.
Building on Solaris 2.6 (5.6) and running on Solaris 8, though, is
supported.
You m
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2007-02-21 10:53]:
>
> > The way we were hoping to do this was to have "wildcard" projects, so
> > that each user would have a project synthesized automatically upon
> > login. Then all the project controls (and the cascaded task controls)
> > apply pe
> The way we were hoping to do this was to have "wildcard" projects, so
> that each user would have a project synthesized automatically upon
> login. Then all the project controls (and the cascaded task controls)
> apply per-user.
This is "future work" or "work we hoped to do at one point bu
Hi,
If the qlc driver has instances 0 , 1 and 2 attached, how do I force driver
detach from, let's say instance 2 alone and give that instance to a different
driver let's say mayaqlc, which puts that device in target mode.
I have been experimenting with the following and it doesn't detach from t
* Roland Mainz <[EMAIL PROTECTED]> [2007-02-20 18:44]:
> Stephen Hahn wrote:
> > I would really rather not see the setrlimit(2) emulation in the
> > resource control framework extended.
>
> Why ?
Because the (soft, hard) semantic in the setrlimit emulation code
is... unpleasant to map to
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2007-02-21 01:19]:
>
> >> I would really rather not see the setrlimit(2) emulation in the
> >> resource control framework extended.
> >
> >Why ?
>
> Setrlimit() suffers from a few restrictions:
>
> - it's per process
> - it can only do a s
James Carlson <[EMAIL PROTECTED]> wrote:
> William James writes:
> > On 2/21/07, James Carlson <[EMAIL PROTECTED]> wrote:
> > > William James writes:
> > > > > There's no race. For async signals, system just picks one thread for
> > > > > delivery.
> > > >
> > > > This is bad. Is there no functio
On Wed, 21 Feb 2007 10:53:14 -0500 James Carlson wrote:
> Glenn Fowler writes:
> > On Wed, 21 Feb 2007 10:05:10 -0500 James Carlson wrote:
> > > Binary incompatibility for _what_?
> >
> > at time (t) I post solaris sparc binaries for say, ksh
> > at time (t+1) the solaris implementation relase ch
James Carlson wrote:
> Garrett D'Amore writes:
>
>> Hmm... checkout pthread_kill(3c) you can deliver a signal to a
>> specific thread. But as far as I know you can -only- do this from
>> inside the process containing the thread to be signaled.
>>
>
> Yes, I was mixing two things.
>
>
Garrett D'Amore writes:
> Hmm... checkout pthread_kill(3c) you can deliver a signal to a
> specific thread. But as far as I know you can -only- do this from
> inside the process containing the thread to be signaled.
Yes, I was mixing two things.
You can't send a signal to a specific thread
> Which thread receives signals in a application with multiple threads?
> Only the running one, the main thread or is this picked randomly?
Here's the deal: There are several flavors of signals. I'll suggest a
canonical terminology by describing them.
Synchronous: A signal that is the result of
James Carlson wrote:
>
>
> There are at least two problems with that latter concept. First, as
> previously explained, there's no way to send a signal to a thread.
> You can send it to a _process_, but not to a _thread_. Threads don't
> have separate PIDs. (At least not on any POSIX-conforming s
On Wed, Feb 21, 2007 at 03:29:51PM +, Frank Hofmann wrote:
> I've recently run across this annoucement:
>
> http://openvz.org/news/announcements/new-features-20070215
>
> which notes "live migration" as a new feature. Now since OpenVZ/Virtuozzo
> isn't a hypervisor but a single-kernel thing
Glenn Fowler writes:
> On Wed, 21 Feb 2007 10:05:10 -0500 James Carlson wrote:
> > Binary incompatibility for _what_?
>
> at time (t) I post solaris sparc binaries for say, ksh
> at time (t+1) the solaris implementation relase changes
> and posted binaries no longer work for the new release
> wors
On Wed, 21 Feb 2007 10:05:10 -0500 James Carlson wrote:
> Glenn Fowler writes:
> > > However, if the ATT code already expects this to be "11" for a SunOS
> > > "5.11" version, then I'm fine with what you have now. If you could
> > > pass upstream the feedback, though, that this could break if the
On Wed, 21 Feb 2007, James Carlson wrote:
William James writes:
A couple of possible ideas:
- stick to just the common interfaces, and avoid those that are
either Solaris-specific or Linux-specific.
How can I simulate forkall behaviour in my application?
You probably can't do it on L
On Wed, 21 Feb 2007, William James wrote:
On 2/21/07, James Carlson <[EMAIL PROTECTED]> wrote:
William James writes:
> On 2/21/07, James Carlson <[EMAIL PROTECTED]> wrote:
> > William James writes:
> > > Does Linux or POSIX specify a function which works like Solaris
forkall?
> >
> > No.
>
>
On Wed, 21 Feb 2007, William James wrote:
One of 'em. It's not documented.
Only one of them or any number of them?
I sense a misunderstanding there.
UNIX signals are nothing like the messaging mechanism that e.g. the GTK+
and QT libraries use and call 'signals'.
A "signalable messaging
On Wed, 21 Feb 2007, William James wrote:
On 2/21/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> There's no race. For async signals, system just picks one thread for
>> delivery.
>
>This is bad. Is there no function to define that signals should be
>send to all threads for async signals?
>I mean, just emit some sort of "internal message" (using thread
>synchronization methods) from within your signal handler on e.g. Ctrl+C
>and thereby rely it into the usual "exit processing" your application must
>have anyway ?
Note that you can't do anything complicated from a signal handler
>On 2/21/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>>
>> >> There's no race. For async signals, system just picks one thread for
>> >> delivery.
>> >
>> >This is bad. Is there no function to define that signals should be
>> >send to all threads for async signals?
>>
>> Why? In what circum
On 2/21/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> There's no race. For async signals, system just picks one thread for
>> delivery.
>
>This is bad. Is there no function to define that signals should be
>send to all threads for async signals?
Why? In what circumstances do all threads
>> There's no race. For async signals, system just picks one thread for
>> delivery.
>
>This is bad. Is there no function to define that signals should be
>send to all threads for async signals?
Why? In what circumstances do all threads need to handle an
asynchronous signal?
Casper
___
William James writes:
> > ... and if that's what you are indeed doing, then consider posix_spawn
> > instead. It's already MT-Safe, standardized, and available on Linux.
>
> Does posix_spawn clone all running threads?
No.
The definition of posix_spawn is that a new process is created that
conta
William James writes:
> > A couple of possible ideas:
> >
> > - stick to just the common interfaces, and avoid those that are
> > either Solaris-specific or Linux-specific.
>
> How can I simulate forkall behaviour in my application?
You probably can't do it on Linux, which is a good sign th
Glenn Fowler writes:
> > However, if the ATT code already expects this to be "11" for a SunOS
> > "5.11" version, then I'm fine with what you have now. If you could
> > pass upstream the feedback, though, that this could break if the minor
> > part ever reverts to "0", that would be appreciated.
>
William James writes:
> > One of 'em. It's not documented.
>
> Only one of them or any number of them?
Just one will actually go into the signal handler.
> > You can control which threads can process signals, though. Just set
> > the signal mask.
>
> You mean I can turn off signal handling in
On 2/21/07, James Carlson <[EMAIL PROTECTED]> wrote:
Frank Hofmann writes:
> I.e. as far as practial applicability goes, if you fork() in a MT process,
> you only fork in order to exec. Don't even think of doing anything else
> but exec in the child after you forked. It's not portable programming
On 2/21/07, James Carlson <[EMAIL PROTECTED]> wrote:
William James writes:
> On 2/21/07, James Carlson <[EMAIL PROTECTED]> wrote:
> > On Linux, I don't think you can do it. This isn't a Linux-related
> > list, though, so if you're trying to port from Solaris to Linux
> > (why?), perhaps you'd ge
Frank Hofmann writes:
> I.e. as far as practial applicability goes, if you fork() in a MT process,
> you only fork in order to exec. Don't even think of doing anything else
> but exec in the child after you forked. It's not portable programming.
... and if that's what you are indeed doing, then
>So all threads call the signal callback at the same time? Can I use
>pthread_mutex_lock() in the signal handler to prevent a race
>condition?
No, at most one signal handler is called and only a (random)
thread interested in receiving the signal will get it.
Casper
_
On Tue, 20 Feb 2007 23:26:33 -0800 (PST) [EMAIL PROTECTED] wrote:
> >> I guess I'm wondering though what sort of release values are used with
> >> other systems? Could it instead be based on something like (major # *
> >> 100) + (minor #?)
> >
> > In any case this would AFAIK require major change
On Wed, 21 Feb 2007, William James wrote:
On 2/21/07, James Carlson <[EMAIL PROTECTED]> wrote:
William James writes:
> On 2/21/07, Vincenzo Sciarra <[EMAIL PROTECTED]> wrote:
> > All threads receive the signal. Better, the main thread receive the
signal but it shares the signal with other thre
On 2/21/07, James Carlson <[EMAIL PROTECTED]> wrote:
William James writes:
> On 2/21/07, James Carlson <[EMAIL PROTECTED]> wrote:
> > William James writes:
> > > > There's no race. For async signals, system just picks one thread for
> > > > delivery.
> > >
> > > This is bad. Is there no function
William James writes:
> On 2/21/07, James Carlson <[EMAIL PROTECTED]> wrote:
> > William James writes:
> > > > There's no race. For async signals, system just picks one thread for
> > > > delivery.
> > >
> > > This is bad. Is there no function to define that signals should be
> > > send to all thr
William James writes:
> On 2/21/07, James Carlson <[EMAIL PROTECTED]> wrote:
> > On Linux, I don't think you can do it. This isn't a Linux-related
> > list, though, so if you're trying to port from Solaris to Linux
> > (why?), perhaps you'd get better answers on a different list.
>
> I wish to wr
On 2/21/07, James Carlson <[EMAIL PROTECTED]> wrote:
William James writes:
> > There's no race. For async signals, system just picks one thread for
> > delivery.
>
> This is bad. Is there no function to define that signals should be
> send to all threads for async signals?
You don't (and can't)
William James writes:
> > There's no race. For async signals, system just picks one thread for
> > delivery.
>
> This is bad. Is there no function to define that signals should be
> send to all threads for async signals?
You don't (and can't) send signals to threads. You send them to
processes.
On 2/21/07, James Carlson <[EMAIL PROTECTED]> wrote:
William James writes:
> On 2/21/07, Vincenzo Sciarra <[EMAIL PROTECTED]> wrote:
> > All threads receive the signal. Better, the main thread receive the signal
but it shares the signal with other threads.
> >
> >
> >
> > Dott. Vincenzo Sciarra
On 2/21/07, James Carlson <[EMAIL PROTECTED]> wrote:
William James writes:
> On 2/21/07, James Carlson <[EMAIL PROTECTED]> wrote:
> > William James writes:
> > > Does Linux or POSIX specify a function which works like Solaris forkall?
> >
> > No.
>
> How can I fork all running threads in an appli
On 2/21/07, Frank Hofmann <[EMAIL PROTECTED]> wrote:
On Wed, 21 Feb 2007, William James wrote:
[ ... ]
> Does forkall() clone all running threads?
Solaris manpages are just wonderful :)
fork(2) says:
[ ... ]
Threads
A call to forkall() replicates in the child process all of
t
William James writes:
> On 2/21/07, James Carlson <[EMAIL PROTECTED]> wrote:
> > William James writes:
> > > Does Linux or POSIX specify a function which works like Solaris forkall?
> >
> > No.
>
> How can I fork all running threads in an application on Linux or other
> POSIX operating systems?
O
On 2/21/07, James Carlson <[EMAIL PROTECTED]> wrote:
William James writes:
> Does Linux or POSIX specify a function which works like Solaris forkall?
No.
How can I fork all running threads in an application on Linux or other
POSIX operating systems?
Cheers,
William
--
@,,@ William James
William James writes:
> On 2/21/07, Vincenzo Sciarra <[EMAIL PROTECTED]> wrote:
> > All threads receive the signal. Better, the main thread receive the signal
> > but it shares the signal with other threads.
> >
> >
> >
> > Dott. Vincenzo Sciarra
>
> So all threads call the signal callback at th
William James writes:
> Does Linux or POSIX specify a function which works like Solaris forkall?
No.
Perhaps this will help a bit:
http://developers.sun.com/solaris/articles/solaris_linux_app.html
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 1 Netw
On Wed, 21 Feb 2007, William James wrote:
[ ... ]
Does forkall() clone all running threads?
Solaris manpages are just wonderful :)
fork(2) says:
[ ... ]
Threads
A call to forkall() replicates in the child process all of
the threads (see thr_create(3C) and pthread_create(3C))
Does Linux or POSIX specify a function which works like Solaris forkall?
Cheers,
William
--
@,,@ William James
(\--/) [EMAIL PROTECTED]
(.>__<.) GNU/Solaris hacker
___
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.o
On 2/21/07, Vincenzo Sciarra <[EMAIL PROTECTED]> wrote:
All threads receive the signal. Better, the main thread receive the signal but
it shares the signal with other threads.
Dott. Vincenzo Sciarra
So all threads call the signal callback at the same time? Can I use
pthread_mutex_lock() in
All threads receive the signal. Better, the main thread receive the signal but
it shares the signal with other threads.
Dott. Vincenzo Sciarra
This message posted from opensolaris.org
___
opensolaris-code mailing list
opensolaris-code@opensolaris.
Which thread receives signals in a application with multiple threads?
Only the running one, the main thread or is this picked randomly?
Cheers,
William
--
@,,@ William James
(\--/) [EMAIL PROTECTED]
(.>__<.) GNU/Solaris hacker
___
opensolaris-c
On 2/21/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>Does forkall() clone all running threads?
Is it really to much to ask to read the manual page?
(Yes)
Sorry but I am now reinstalling Solaris and do not have access to the
manual paghne.
Cheers,
William
--
@,,@ William James
(\
>Does forkall() clone all running threads?
Is it really to much to ask to read the manual page?
(Yes)
Casper
___
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
On 2/21/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>The fork() in the program using the Solaris threads that is called
>from the program using the POSIX thread run in the POSIX threads
>semantic.
>Can I run the fork() in the Solaris threads semantic on Solaris 9?
Unclear; one reason why t
>The fork() in the program using the Solaris threads that is called
>from the program using the POSIX thread run in the POSIX threads
>semantic.
>Can I run the fork() in the Solaris threads semantic on Solaris 9?
Unclear; one reason why the Solaris thread semantics were changed
is simple, it is u
The fork() in the program using the Solaris threads that is called
from the program using the POSIX thread run in the POSIX threads
semantic.
Can I run the fork() in the Solaris threads semantic on Solaris 9?
The following is how to compile and link:
cc fork.c -G -o libfork.so -D_REENTRANT -lthre
>Do programs work properly as long as the programs use API in libpthread.so,
>libthread.so or libc.so?
Programs work properly as long as they:
- test return codes and handle failures appropriately
- do not link library against libthread/libpthread
- do not attempt to crea
On Wed, 21 Feb 2007, Tsutomu Enokida wrote:
The following programs work well. Is there any conditions?
Non-trivial testcases. Your 'libsub1.so' doesn't _DEPEND_ on being
compiled -D_POSIX_C_SOURCE=..., it makes no use of any threading
facilities whatsoever.
What does the code below prove/d
Do programs work properly as long as the programs use API in libpthread.so,
libthread.so or libc.so?
Thank you,
Enokdia
Sent: Wednesday, February 21, 2007 8:09 PM
Subject: Re: [osol-code] Any problems with providing only shared librarys linked with libpthread.so
The following programs wo
>The following programs work well. Is there any conditions?
The linking works just fine and loading the library may also
work just fine.
But more complex usage can easily run into the dreaded
"_rmutex_unlock: rmutex not held" errors
Casper
___
openso
The following programs work well. Is there any conditions?
cc -xCC -G -D_POSIX_C_SOURCE=199506L sub1.c -o libsub1.so -lpthread
cc dltest.c -ldl
-- dltest.c
main() {
void * hd1;
int (*fptr1)(void);
if(!(hd1=dlopen("libsub1.so",RTLD_NOW)))
printf("dlopen %s\n",dle
Roland Mainz <[EMAIL PROTECTED]> wrote:
> > Perhaps an OpenSolaris-specific
> > function in ksh93 to call setrctl(2) directly would be more
> > appropriate. (Plus we don't have process-level controls for some of
> > these resources today.)
>
> There are two problems:
> 1. "ulimit" works p
Alan Coopersmith <[EMAIL PROTECTED]> wrote:
> In the open source world, many projects follow the FSF rule of thumb,
> which states changes fewer than 10-15 lines of code are not significant
> enough to earn copyright protection - you can see this in the FSF
> Contributor Agreement docs at:
>ht
I have just published on http://nutmay.sourceforge.net a Proof of Concept
document to fix what I'm doing.
Thanks
This message posted from opensolaris.org
___
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.or
>> I would really rather not see the setrlimit(2) emulation in the
>> resource control framework extended.
>
>Why ?
Setrlimit() suffers from a few restrictions:
- it's per process
- it can only do a soft and hard limit.
Per process limits have a drawback in that the actual
[EMAIL PROTECTED] wrote:
Actually, I don't think that's what needs to be asked.
What I suggested asking Bonnie about was whether or not this change
requires a Sun copyright to be added. I don't believe adding a CDDL
block to the ATT code is appropriate but for ON, we typically add a Sun
copyri
79 matches
Mail list logo
