Jose Marcio Martins da Cruz wrote:
Julian Elischer wrote:
Jose Marcio Martins da Cruz wrote:
So, if I understood, the better I can do is, instead of letting the
child follow
a different path after the fork, he shall better do an exec of
another thing and
start a clean process...
of
On Jan 26, 2006, at 12:55 AM, Jose Marcio Martins da Cruz wrote:
Can you point me a good doc about threads, signals, and such kind
of things in
FreeBSD context ?
David Butenhof's book, "Programming with POSIX Threads", includes a
good discussion of signals in the context of pthreads. How t
Jose Marcio Martins da Cruz wrote:
Hello,
Julian Elischer wrote:
Jose Marcio Martins da Cruz wrote:
also, does the child do an exec() after forking?
No. The child gets out the father loop and calls another
initialisation function.
The Posix spec says that after
Hello,
Julian Elischer wrote:
> Jose Marcio Martins da Cruz wrote:
>>> also, does the child do an exec() after forking?
>>
>> No. The child gets out the father loop and calls another
>> initialisation function.
>
> The Posix spec says that after a fork(0 teh child must do almost nothing
> befor
Julian Elischer wrote:
Jose Marcio Martins da Cruz wrote:
Julian Elischer wrote:
Jose Marcio Martins da Cruz wrote:
a new threading library.
H.
Here are my compile flags :
CPPFLAGS : only some -I and -D flags
CFLAGS : -D_THREAD_SAFE -pthread
LDFLAGS : -lmilter -lkvm -lm -l
Jose Marcio Martins da Cruz wrote:
Julian Elischer wrote:
Jose Marcio Martins da Cruz wrote:
a new threading library.
H.
Here are my compile flags :
CPPFLAGS : only some -I and -D flags
CFLAGS : -D_THREAD_SAFE -pthread
LDFLAGS : -lmilter -lkvm -lm -lpthread
have you tried 6
Julian Elischer wrote:
Jose Marcio Martins da Cruz wrote:
a new threading library.
H.
Here are my compile flags :
CPPFLAGS : only some -I and -D flags
CFLAGS : -D_THREAD_SAFE -pthread
LDFLAGS : -lmilter -lkvm -lm -lpthread
have you tried 6.0?
Yes. It presents the same behaviour.
SIGABRT and exits immediately when it launches the signal handler
thread.
I solved this by replacing the signal handling of the father : using a handler
defined with sigaction instead of using a thread. But I'd like to understanding
what's wrong with this and what changed from FreeBSD 5.
launches the signal handler
thread.
I solved this by replacing the signal handling of the father : using a handler
defined with sigaction instead of using a thread. But I'd like to understanding
what's wrong with this and what changed from FreeBSD 5.2.1 to 5.3
Thanks
J
hello,
i have a daemon program and installed a
signal_handler() function for it. from signal_handler:
case SIGCHLD:
if ((wait(&status)) == -1) return;
if (WIFSIGNALED(status)) return;
if (WIFSTOPPED(status)) return;
if (WIFEXITED(status)) return;
break;
in child process i am doing a
On Thu, 8 Jan 2004, rmkml wrote:
> please can you give me an example
> of mask to SET BLOCK ou UNBLOCK
> in both threads (main and run)
> in order to make this sample code working ?
man pthread_sigmask
sigset_t set;
sigemptyset(&set);
sigsetadd(&set, SIGINT);
pth
ED]>
> To: rmkml <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: problem with signal handling and threads (fbsd49R)
>
> On Thu, 8 Jan 2004, rmkml wrote:
>
> > Hi,
> >
> > I've got a problem with signal handling and threads.
> > I'
On Thu, 8 Jan 2004, rmkml wrote:
> Hi,
>
> I've got a problem with signal handling and threads.
> I've reproduced the problem in a simple code.
> Description of program:
> install a signal handler SIGINT.
> create a thread that do nothing except waiting.
Hi,
I've got a problem with signal handling and threads.
I've reproduced the problem in a simple code.
Description of program:
install a signal handler SIGINT.
create a thread that do nothing except waiting.
main thread use poll to wait forever [ poll(,,-1) ].
user has too
On Sun, Sep 02, 2001 at 09:55:03AM -0700, David O'Brien wrote:
> The PIM Evolution, http://www.ximian.com/products/ximian_evolution/,
> does not run on FreeBSD. The authors have made a change so that it will.
> However, we would like to know if FreeBSD is the odd-man-out, or if the
> authors were
bout "proper handling",
if I recall correctly. FWIW, I opposed the change (which
implied SA_CLDWAIT, I think, with no way to turn it off to get
historical behaviour for programs which needed it).
I hate POSIX signal handling...
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Hi Hackers, et.al.
The PIM Evolution, http://www.ximian.com/products/ximian_evolution/,
does not run on FreeBSD. The authors have made a change so that it will.
However, we would like to know if FreeBSD is the odd-man-out, or if the
authors were lucky Evolution ran on Solaris and Linux.
-
Mon, Aug 13, 2001 at 09:09:32, zaunere (Hans Zaunere) wrote about "Signal Handling":
> In a program that I am working on, I've decided to
> catch signal 15, which then calls execl() in the
> handler to reload the program from the on-disk binary.
> I am able to sen
way in some oold Unixen.
The sigaction(2) syscall gives you much more control over how
your handlers are called/reset/etc.
> 2) If a 10k binary is running, the signal is sent, and
> the program is reloaded from disk, but is 100k (or 1k
> even) how does the signal handling function get
> c
On Tue, Aug 14, 2001 at 09:11:58PM -0700, brian o'shea wrote:
> On Tue, Aug 14, 2001 at 07:47:50PM -0700, Hans Zaunere wrote:
> > > [...]
> > > > 2) If a 10k binary is running, the signal is sent, and the program
> > > > is reloaded from disk, but is 100k
On Tue, Aug 14, 2001 at 07:47:50PM -0700, Hans Zaunere wrote:
> > [...]
> > > 2) If a 10k binary is running, the signal is sent, and the program
> > > is reloaded from disk, but is 100k (or 1k even) how does the
> > > signal handling function get called, takin
> [...]
> > 2) If a 10k binary is running, the signal is sent,
> and
> > the program is reloaded from disk, but is 100k (or
> 1k
> > even) how does the signal handling function get
> > called, taking into account what Stevens says.
> Steven
> > states
If while the handler is executing, the process receives
signal 15 again, you don't want the signal handler to be called while it
is already executing. Anybody else have some input on this?
> 2) If a 10k binary is running, the signal is sent, and
> the program is reloaded from disk, bu
become
blocked after it is recieved? Why does the kernel
want to do this?
2) If a 10k binary is running, the signal is sent, and
the program is reloaded from disk, but is 100k (or 1k
even) how does the signal handling function get
called, taking into account what Stevens says. Steven
states that
I'm wondering if anyone has the time or inclination to take a look at a fix
for PR bin/25110. We're having problems using a freshly-built 4.2-stable
box (technically 4.3 rc at this point), and the bug is still present.
I'm not sure how many people would see this problem (we see it because we
hav
gt;if the signal has been marked as SIG_IGN. [...]
>
> So if I set all appropriate signals I want to monitor to SIG_IGN, I
> can essentially have kevent() becoming the primary signal handling
> mechanism in my program?
Correct.
--
Jonathan
To Unsubscribe: send mail to [EMAIL P
can essentially have kevent() becoming the primary signal handling
mechanism in my program?
Thanks in advance.
Regards,
Trent.
--
Trent Nelson - Software Engineer - [EMAIL PROTECTED]
"A man with unlimited enthusiasm can achieve
almost anything." --unknown
nues with the instruction after semop, as if it was unblocked by
> successful semop.
>
> Is this behaviour normal, and is there a way for the process to
> distinguish
> between signal handling unblock and successful semop operation (may be
> by
> setting a global variable in
semop, as if it was unblocked by
successful semop.
Is this behaviour normal, and is there a way for the process to distinguish
between signal handling unblock and successful semop operation (may be by
setting a global variable in the signal-handling function) ?
Thank you in advance.
Vladimir
29 matches
Mail list logo
