Re: [9fans] syscall silently kill processes
On Fri, 17 Jun 2022, andrey100100...@gmail.com wrote: Seems like noted() call not needed in user code. noted() is only needed when using the syscall notify, when using atnotify() (or threadnotify) you don't need it, as it is said in notify(2) and you did correctly in your first example. threadnotify doesn't kill your process if there is no space free in onnote[], onnotepid[], the handler is not registered, that's all. alarm() should send the note to the process and the first handler registered with the note "alarm" should be executed. Your handler checked for the note and returned non zero, the process should continue. When read is interrupted, it should return an error, the process should not be killed. Here is the issue. Comment the read statement and there will be the same number of "end"s as "start"s. Note that you could register the handler in threadmain and avoid completely this issue, but as I said before, something seems wrong to me here. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tfa6823048ad90a21-Madcf140195c52ad821869376 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] syscall silently kill processes
On 6/17/22 12:48, andrey100100...@gmail.com wrote:
> В Пт, 17/06/2022 в 10:11 -0600, Jacob Moody пишет:
>> On 6/17/22 09:06, andrey100100...@gmail.com wrote:
>>> В Пт, 17/06/2022 в 08:11 -0600, Jacob Moody пишет:
On 6/17/22 07:46, Thaddeus Woskowiak wrote:
> I believe threadnotify() should be called from threadmain() to
> properly register the handler in the rendez group
This is incorrect, according to thread(2):
"The thread library depends on all procs
being in the same rendezvous group"
>>>
>>>
>>> From sleep(2):
>>>
>>> Alarm causes an alarm note (see notify(2)) to be sent to the
>>> invoking process after the number of milliseconds given by
>>> the argument.
>>>
>>> Mean to be sent only to the invoking process, NOT to the process
>>> group.
>>
>> Yes this is correct, If I implied otherwise I apologize. My point
>> with
>> pointing out that excerpt is that groups likely had nothing to do
>> with this.
>>
The issue here is that your note handler has to call noted,
you are returning from the handler without actually resuming the
program.
You either need to call noted(NCONT) to resume execution or
noted(NDFLT)
to stop execution.
An excerpt from notify(2):
"A notification handler must finish either by exiting the
program or by calling noted; if the handler returns the
behavior is undefined and probably erroneous."
So you are indeed observing undefined behavior.
>>>
>>> With:
>>>
>>>
>>> static int
>>> handler_alarm(void *, char *msg)
>>> {
>>> if(strstr(msg, "alarm")){
>>> noted(NCONT);
>>> return 1;
>>> }
>>>
>>> return 0;
>>> }
>>>
>>> result the same:
>>>
>>> cpu% 6.out | grep end | wc -l
>>> 33
>>>
>>>
>>> And noted(NCONT) may be needed, when process recieved many (2 and
>>> more)
>>> notes at once.
>>>
>>> May be something wrong with interrupted an incomplete system
>>> call?
>>
>> You _always_ should call either noted(NCONT) or noted(NDFLT).
>
> But from atnotify(2) (section 'Atnotify'):
>
> When the system
> posts a note to the process, each handler registered with
> atnotify is called with arguments as described above until
> one of the handlers returns non-zero. Then noted is called
> with argument NCONT. If no registered function returns
> non-zero, atnotify calls noted with argument NDFLT.
>
> from /sys/src/libc/port/atnotify.c :
>
>
> static
> void
> notifier(void *v, char *s)
> {
> int i;
>
> for(i=0; i if(onnot[i] && ((*onnot[i])(v, s))){
> noted(NCONT);
> return;
> }
> noted(NDFLT);
> }
>
>
> Seems like noted() call not needed in user code.
>
Oh look at that, my apologies. That's the whole difference
between just notify() and atnotify(), how did I miss that.
>> But you are correct in that this wasn't the exact issue. I poked
>> around with the code a bit. I rewrote it to just use
>> fork(), and I got all 80 "end" messages.
>
> Yes, with fork() is working:
>
> --
> #include
> #include
>
> static int
> handler_alarm(void *, char *msg)
> {
> if(strstr(msg, "alarm"))
> return 1;
>
> return 0;
> }
>
> static void
> proc_udp(void *)
> {
> char resp[512];
> char req[] = "request";
> int fd;
>
> atnotify(handler_alarm, 1);
>
> if((fd = dial("udp!185.157.221.201!5678", nil, nil, nil)) >=
> 0){
> if(write(fd, req, strlen(req)) == strlen(req)){
> fprint(1, "start\n");
> alarm(2000);
> read(fd, resp, sizeof(resp));
> alarm(0);
> fprint(1, "end\n");
> }
> close(fd);
> }
>
> }
>
> void
> main(int argc, char *argv[])
> {
> for(int i = 0; i < 80; i++){
> switch(fork()){
> case -1:
> sysfatal("fork: %r");
> case 0:
> proc_udp(nil);
> exits(nil);
> }
> }
>
> sleep(5000);
> exits(nil);
> }
> --
>
> cpu% 6.out | grep end | wc -l
> 80
>
> But with rfork(RFPROC|RFMEM|RFNOWAIT) (the same, how in proccreate)
> not:
>
> cpu% 6.out | grep end | wc -l
> 6
>
> strange...
>
>> So I suspected
>> libthread had some arbitrary limit:
>>
>> #define NFN 33
>> #define ERRLEN 48
>> typedef struct Note Note;
>>
Re: [9fans] syscall silently kill processes
В Пт, 17/06/2022 в 10:11 -0600, Jacob Moody пишет:
> On 6/17/22 09:06, andrey100100...@gmail.com wrote:
> > В Пт, 17/06/2022 в 08:11 -0600, Jacob Moody пишет:
> > > On 6/17/22 07:46, Thaddeus Woskowiak wrote:
> > > > I believe threadnotify() should be called from threadmain() to
> > > > properly register the handler in the rendez group
> > >
> > > This is incorrect, according to thread(2):
> > >
> > > "The thread library depends on all procs
> > > being in the same rendezvous group"
> >
> >
> > From sleep(2):
> >
> > Alarm causes an alarm note (see notify(2)) to be sent to the
> > invoking process after the number of milliseconds given by
> > the argument.
> >
> > Mean to be sent only to the invoking process, NOT to the process
> > group.
>
> Yes this is correct, If I implied otherwise I apologize. My point
> with
> pointing out that excerpt is that groups likely had nothing to do
> with this.
>
> > >
> > > The issue here is that your note handler has to call noted,
> > > you are returning from the handler without actually resuming the
> > > program.
> > > You either need to call noted(NCONT) to resume execution or
> > > noted(NDFLT)
> > > to stop execution.
> > >
> > > An excerpt from notify(2):
> > >
> > > "A notification handler must finish either by exiting the
> > > program or by calling noted; if the handler returns the
> > > behavior is undefined and probably erroneous."
> > >
> > > So you are indeed observing undefined behavior.
> > >
> >
> > With:
> >
> >
> > static int
> > handler_alarm(void *, char *msg)
> > {
> > if(strstr(msg, "alarm")){
> > noted(NCONT);
> > return 1;
> > }
> >
> > return 0;
> > }
> >
> > result the same:
> >
> > cpu% 6.out | grep end | wc -l
> > 33
> >
> >
> > And noted(NCONT) may be needed, when process recieved many (2 and
> > more)
> > notes at once.
> >
> > May be something wrong with interrupted an incomplete system
> > call?
>
> You _always_ should call either noted(NCONT) or noted(NDFLT).
But from atnotify(2) (section 'Atnotify'):
When the system
posts a note to the process, each handler registered with
atnotify is called with arguments as described above until
one of the handlers returns non-zero. Then noted is called
with argument NCONT. If no registered function returns
non-zero, atnotify calls noted with argument NDFLT.
from /sys/src/libc/port/atnotify.c :
static
void
notifier(void *v, char *s)
{
int i;
for(i=0; i But you are correct in that this wasn't the exact issue. I poked
> around with the code a bit. I rewrote it to just use
> fork(), and I got all 80 "end" messages.
Yes, with fork() is working:
--
#include
#include
static int
handler_alarm(void *, char *msg)
{
if(strstr(msg, "alarm"))
return 1;
return 0;
}
static void
proc_udp(void *)
{
char resp[512];
char req[] = "request";
int fd;
atnotify(handler_alarm, 1);
if((fd = dial("udp!185.157.221.201!5678", nil, nil, nil)) >=
0){
if(write(fd, req, strlen(req)) == strlen(req)){
fprint(1, "start\n");
alarm(2000);
read(fd, resp, sizeof(resp));
alarm(0);
fprint(1, "end\n");
}
close(fd);
}
}
void
main(int argc, char *argv[])
{
for(int i = 0; i < 80; i++){
switch(fork()){
case -1:
sysfatal("fork: %r");
case 0:
proc_udp(nil);
exits(nil);
}
}
sleep(5000);
exits(nil);
}
--
cpu% 6.out | grep end | wc -l
80
But with rfork(RFPROC|RFMEM|RFNOWAIT) (the same, how in proccreate)
not:
cpu% 6.out | grep end | wc -l
6
strange...
> So I suspected
> libthread had some arbitrary limit:
>
> #define NFN 33
> #define ERRLEN 48
> typedef struct Note Note;
> struct Note
> {
> Lock inuse;
> Proc *proc; /* recipient */
> char s[ERRMAX]; /* arg2 */
> };
>
> static Note notes[128];
> static Note *enotes = notes+nelem(notes);
> static int (*onnote[NFN])(void*, char*);
> static int onnotepid[NFN];
> static Lock onnotelock;
>
> int
> threadnotify(int (*f)(void*, char*), int in)
> {
> int i, topid;
> int (*from)(void*, char*), (*to)(void*, char*);
>
> if(in){
> from = nil;
> to = f;
>
Re: [9fans] syscall silently kill processes
On Fri, 17 Jun 2022, Skip Tavakkolian wrote: Thanks to Douglas Adams, I think '42' might be a more obvious magic number for a clue: % 8c udpflood.c && 8l -o udpflood udpflood.8 && ./udpflood | grep end | wc -l 42 % grep 42 /sys/src/libthread/note.c #define NFN 42 I don't understand, why does it work when commenting out the read statement? Why it doesn't work even removing all the notification handling? Maybe I have it all wrong, but I think there is more to this. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tfa6823048ad90a21-M346082debc6a2d5b01267879 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] syscall silently kill processes
Thanks to Douglas Adams, I think '42' might be a more obvious magic
number for a clue:
% 8c udpflood.c && 8l -o udpflood udpflood.8 && ./udpflood | grep end | wc -l
42
% grep 42 /sys/src/libthread/note.c
#define NFN 42
On Fri, Jun 17, 2022 at 9:11 AM Skip Tavakkolian
wrote:
>
> it's worth grepping for persistent magic constants:
>
> % grep 33 /sys/src/libthread/*.[ch]
> /sys/src/libthread/note.c:#define NFN 33
>
> On Fri, Jun 17, 2022 at 9:08 AM Skip Tavakkolian
> wrote:
> >
> > interesting catch. it seems to be a tunable limit.
> >
> > % grep NFN /sys/src/libthread/note.c
> > #define NFN 33
> > static int (*onnote[NFN])(void*, char*);
> > static int onnotepid[NFN];
> > for(i=0; i > return i > for(i=0; i > if(i==NFN){
> >
> > On Fri, Jun 17, 2022 at 8:08 AM wrote:
> > >
> > > В Пт, 17/06/2022 в 08:11 -0600, Jacob Moody пишет:
> > > > On 6/17/22 07:46, Thaddeus Woskowiak wrote:
> > > > > I believe threadnotify() should be called from threadmain() to
> > > > > properly register the handler in the rendez group
> > > >
> > > > This is incorrect, according to thread(2):
> > > >
> > > > "The thread library depends on all procs
> > > > being in the same rendezvous group"
> > >
> > >
> > > From sleep(2):
> > >
> > > Alarm causes an alarm note (see notify(2)) to be sent to the
> > > invoking process after the number of milliseconds given by
> > > the argument.
> > >
> > > Mean to be sent only to the invoking process, NOT to the process group.
> > >
> > > >
> > > > The issue here is that your note handler has to call noted,
> > > > you are returning from the handler without actually resuming the
> > > > program.
> > > > You either need to call noted(NCONT) to resume execution or
> > > > noted(NDFLT)
> > > > to stop execution.
> > > >
> > > > An excerpt from notify(2):
> > > >
> > > > "A notification handler must finish either by exiting the
> > > > program or by calling noted; if the handler returns the
> > > > behavior is undefined and probably erroneous."
> > > >
> > > > So you are indeed observing undefined behavior.
> > > >
> > >
> > > With:
> > >
> > >
> > > static int
> > > handler_alarm(void *, char *msg)
> > > {
> > > if(strstr(msg, "alarm")){
> > > noted(NCONT);
> > > return 1;
> > > }
> > >
> > > return 0;
> > > }
> > >
> > >
> > > result the same:
> > >
> > > cpu% 6.out | grep end | wc -l
> > > 33
> > >
> > >
> > > And noted(NCONT) may be needed, when process recieved many (2 and more)
> > > notes at once.
> > >
> > > May be something wrong with interrupted an incomplete system call?
> > >
> > >
> > > >
> > > > Hope this helps,
> > > > moody
> > > >
> > >
> > >
> > > Regards,
> > > Andrej
> > >
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Tfa6823048ad90a21-M5b827bf9eba38f893c1f67bb
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] syscall silently kill processes
On 6/17/22 09:06, andrey100100...@gmail.com wrote:
> В Пт, 17/06/2022 в 08:11 -0600, Jacob Moody пишет:
>> On 6/17/22 07:46, Thaddeus Woskowiak wrote:
>>> I believe threadnotify() should be called from threadmain() to
>>> properly register the handler in the rendez group
>>
>> This is incorrect, according to thread(2):
>>
>> "The thread library depends on all procs
>> being in the same rendezvous group"
>
>
> From sleep(2):
>
> Alarm causes an alarm note (see notify(2)) to be sent to the
> invoking process after the number of milliseconds given by
> the argument.
>
> Mean to be sent only to the invoking process, NOT to the process group.
Yes this is correct, If I implied otherwise I apologize. My point with
pointing out that excerpt is that groups likely had nothing to do with this.
>>
>> The issue here is that your note handler has to call noted,
>> you are returning from the handler without actually resuming the
>> program.
>> You either need to call noted(NCONT) to resume execution or
>> noted(NDFLT)
>> to stop execution.
>>
>> An excerpt from notify(2):
>>
>> "A notification handler must finish either by exiting the
>> program or by calling noted; if the handler returns the
>> behavior is undefined and probably erroneous."
>>
>> So you are indeed observing undefined behavior.
>>
>
> With:
>
>
> static int
> handler_alarm(void *, char *msg)
> {
> if(strstr(msg, "alarm")){
> noted(NCONT);
> return 1;
> }
>
> return 0;
> }
>
> result the same:
>
> cpu% 6.out | grep end | wc -l
> 33
>
>
> And noted(NCONT) may be needed, when process recieved many (2 and more)
> notes at once.
>
> May be something wrong with interrupted an incomplete system call?
You _always_ should call either noted(NCONT) or noted(NDFLT).
But you are correct in that this wasn't the exact issue. I poked
around with the code a bit. I rewrote it to just use
fork(), and I got all 80 "end" messages. So I suspected
libthread had some arbitrary limit:
#define NFN 33
#define ERRLEN 48
typedef struct Note Note;
struct Note
{
Lockinuse;
Proc*proc; /* recipient */
chars[ERRMAX]; /* arg2 */
};
static Note notes[128];
static Note *enotes = notes+nelem(notes);
static int (*onnote[NFN])(void*, char*);
static int onnotepid[NFN];
static Lock onnotelock;
int
threadnotify(int (*f)(void*, char*), int in)
{
int i, topid;
int (*from)(void*, char*), (*to)(void*, char*);
if(in){
from = nil;
to = f;
topid = _threadgetproc()->pid;
}else{
from = f;
to = nil;
topid = 0;
}
lock();
for(i=0; ihttps://9fans.topicbox.com/groups/9fans/Tfa6823048ad90a21-M687ef3adb4df6c21a188e7e1
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] syscall silently kill processes
it's worth grepping for persistent magic constants:
% grep 33 /sys/src/libthread/*.[ch]
/sys/src/libthread/note.c:#define NFN 33
On Fri, Jun 17, 2022 at 9:08 AM Skip Tavakkolian
wrote:
>
> interesting catch. it seems to be a tunable limit.
>
> % grep NFN /sys/src/libthread/note.c
> #define NFN 33
> static int (*onnote[NFN])(void*, char*);
> static int onnotepid[NFN];
> for(i=0; i return i for(i=0; i if(i==NFN){
>
> On Fri, Jun 17, 2022 at 8:08 AM wrote:
> >
> > В Пт, 17/06/2022 в 08:11 -0600, Jacob Moody пишет:
> > > On 6/17/22 07:46, Thaddeus Woskowiak wrote:
> > > > I believe threadnotify() should be called from threadmain() to
> > > > properly register the handler in the rendez group
> > >
> > > This is incorrect, according to thread(2):
> > >
> > > "The thread library depends on all procs
> > > being in the same rendezvous group"
> >
> >
> > From sleep(2):
> >
> > Alarm causes an alarm note (see notify(2)) to be sent to the
> > invoking process after the number of milliseconds given by
> > the argument.
> >
> > Mean to be sent only to the invoking process, NOT to the process group.
> >
> > >
> > > The issue here is that your note handler has to call noted,
> > > you are returning from the handler without actually resuming the
> > > program.
> > > You either need to call noted(NCONT) to resume execution or
> > > noted(NDFLT)
> > > to stop execution.
> > >
> > > An excerpt from notify(2):
> > >
> > > "A notification handler must finish either by exiting the
> > > program or by calling noted; if the handler returns the
> > > behavior is undefined and probably erroneous."
> > >
> > > So you are indeed observing undefined behavior.
> > >
> >
> > With:
> >
> >
> > static int
> > handler_alarm(void *, char *msg)
> > {
> > if(strstr(msg, "alarm")){
> > noted(NCONT);
> > return 1;
> > }
> >
> > return 0;
> > }
> >
> >
> > result the same:
> >
> > cpu% 6.out | grep end | wc -l
> > 33
> >
> >
> > And noted(NCONT) may be needed, when process recieved many (2 and more)
> > notes at once.
> >
> > May be something wrong with interrupted an incomplete system call?
> >
> >
> > >
> > > Hope this helps,
> > > moody
> > >
> >
> >
> > Regards,
> > Andrej
> >
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Tfa6823048ad90a21-M2b6a9ca6ba8b315c113a43e9
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] syscall silently kill processes
interesting catch. it seems to be a tunable limit.
% grep NFN /sys/src/libthread/note.c
#define NFN 33
static int (*onnote[NFN])(void*, char*);
static int onnotepid[NFN];
for(i=0; i wrote:
>
> В Пт, 17/06/2022 в 08:11 -0600, Jacob Moody пишет:
> > On 6/17/22 07:46, Thaddeus Woskowiak wrote:
> > > I believe threadnotify() should be called from threadmain() to
> > > properly register the handler in the rendez group
> >
> > This is incorrect, according to thread(2):
> >
> > "The thread library depends on all procs
> > being in the same rendezvous group"
>
>
> From sleep(2):
>
> Alarm causes an alarm note (see notify(2)) to be sent to the
> invoking process after the number of milliseconds given by
> the argument.
>
> Mean to be sent only to the invoking process, NOT to the process group.
>
> >
> > The issue here is that your note handler has to call noted,
> > you are returning from the handler without actually resuming the
> > program.
> > You either need to call noted(NCONT) to resume execution or
> > noted(NDFLT)
> > to stop execution.
> >
> > An excerpt from notify(2):
> >
> > "A notification handler must finish either by exiting the
> > program or by calling noted; if the handler returns the
> > behavior is undefined and probably erroneous."
> >
> > So you are indeed observing undefined behavior.
> >
>
> With:
>
>
> static int
> handler_alarm(void *, char *msg)
> {
> if(strstr(msg, "alarm")){
> noted(NCONT);
> return 1;
> }
>
> return 0;
> }
>
>
> result the same:
>
> cpu% 6.out | grep end | wc -l
> 33
>
>
> And noted(NCONT) may be needed, when process recieved many (2 and more)
> notes at once.
>
> May be something wrong with interrupted an incomplete system call?
>
>
> >
> > Hope this helps,
> > moody
> >
>
>
> Regards,
> Andrej
>
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Tfa6823048ad90a21-Mb2e0af1ac4067b7f4649d000
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] syscall silently kill processes
В Пт, 17/06/2022 в 08:11 -0600, Jacob Moody пишет:
> On 6/17/22 07:46, Thaddeus Woskowiak wrote:
> > I believe threadnotify() should be called from threadmain() to
> > properly register the handler in the rendez group
>
> This is incorrect, according to thread(2):
>
> "The thread library depends on all procs
> being in the same rendezvous group"
>From sleep(2):
Alarm causes an alarm note (see notify(2)) to be sent to the
invoking process after the number of milliseconds given by
the argument.
Mean to be sent only to the invoking process, NOT to the process group.
>
> The issue here is that your note handler has to call noted,
> you are returning from the handler without actually resuming the
> program.
> You either need to call noted(NCONT) to resume execution or
> noted(NDFLT)
> to stop execution.
>
> An excerpt from notify(2):
>
> "A notification handler must finish either by exiting the
> program or by calling noted; if the handler returns the
> behavior is undefined and probably erroneous."
>
> So you are indeed observing undefined behavior.
>
With:
static int
handler_alarm(void *, char *msg)
{
if(strstr(msg, "alarm")){
noted(NCONT);
return 1;
}
return 0;
}
result the same:
cpu% 6.out | grep end | wc -l
33
And noted(NCONT) may be needed, when process recieved many (2 and more)
notes at once.
May be something wrong with interrupted an incomplete system call?
>
> Hope this helps,
> moody
>
Regards,
Andrej
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Tfa6823048ad90a21-M4fa69df14eff60273727c92b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] syscall silently kill processes
On Fri, Jun 17, 2022 at 10:13 AM Jacob Moody wrote: > > On 6/17/22 07:46, Thaddeus Woskowiak wrote: > > I believe threadnotify() should be called from threadmain() to > > properly register the handler in the rendez group > > This is incorrect, according to thread(2): > > "The thread library depends on all procs > being in the same rendezvous group" > Doh! Thanks for the info moody. -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tfa6823048ad90a21-M0d5aad458aafef3bcbf5c79c Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] syscall silently kill processes
On 6/17/22 07:46, Thaddeus Woskowiak wrote: > I believe threadnotify() should be called from threadmain() to > properly register the handler in the rendez group This is incorrect, according to thread(2): "The thread library depends on all procs being in the same rendezvous group" The issue here is that your note handler has to call noted, you are returning from the handler without actually resuming the program. You either need to call noted(NCONT) to resume execution or noted(NDFLT) to stop execution. An excerpt from notify(2): "A notification handler must finish either by exiting the program or by calling noted; if the handler returns the behavior is undefined and probably erroneous." So you are indeed observing undefined behavior. Hope this helps, moody -- 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tfa6823048ad90a21-Mfced9ffce2a92c38458048ad Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
Re: [9fans] syscall silently kill processes
I believe threadnotify() should be called from threadmain() to
properly register the handler in the rendez group.
On Fri, Jun 17, 2022 at 5:39 AM wrote:
>
> Hi all!
>
> Strange behavior of syscall 'read' with signal 'alarm' in followed
> simple program (ip/port - not matter):
>
> ---
> #include
> #include
> #include
>
> static int
> handler_alarm(void *, char *msg)
> {
> if(strstr(msg, "alarm"))
> return 1;
>
> return 0;
> }
>
> static void
> proc_udp(void *)
> {
> char resp[512];
> char req[] = "request";
> int fd;
>
> threadnotify(handler_alarm, 1);
>
> if((fd = dial("udp!185.157.221.201!5678", nil, nil, nil)) >=
> 0){
> if(write(fd, req, strlen(req)) == strlen(req)){
> fprint(1, "start\n");
> alarm(2000);
> read(fd, resp, sizeof(resp));
> alarm(0);
> fprint(1, "end\n");
> }
> close(fd);
> }
>
> threadexits(nil);
> }
>
> int mainstacksize = 5242880;
>
> void
> threadmain(int argc, char *argv[])
> {
> for(int i = 0; i < 80; i++){
> proccreate(proc_udp, nil, 10240);
> }
>
> sleep(5000);
> threadexitsall(nil);
> }
> ---
>
> cpu% 6.out | grep end | wc -l
> 33
>
> sometimes little more or less
> but
>
> cpu% 6.out | grep start | wc -l
> 80
>
> always.
>
> Testing on Miller's RPi and 9front (amd64 & RPi 2)
>
> Why does read() kill process?
> Why not always?
> Why number of 'ended' processes arond 33?
> This is normal behavior?
> How to fix the program so that the processes do not lost?
>
> Can someone point me in the right direction?
>
> Thanks!
> Andrey
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Tfa6823048ad90a21-M799a747eed5b007fc4d07fbe
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[9fans] syscall silently kill processes
Hi all!
Strange behavior of syscall 'read' with signal 'alarm' in followed
simple program (ip/port - not matter):
---
#include
#include
#include
static int
handler_alarm(void *, char *msg)
{
if(strstr(msg, "alarm"))
return 1;
return 0;
}
static void
proc_udp(void *)
{
char resp[512];
char req[] = "request";
int fd;
threadnotify(handler_alarm, 1);
if((fd = dial("udp!185.157.221.201!5678", nil, nil, nil)) >=
0){
if(write(fd, req, strlen(req)) == strlen(req)){
fprint(1, "start\n");
alarm(2000);
read(fd, resp, sizeof(resp));
alarm(0);
fprint(1, "end\n");
}
close(fd);
}
threadexits(nil);
}
int mainstacksize = 5242880;
void
threadmain(int argc, char *argv[])
{
for(int i = 0; i < 80; i++){
proccreate(proc_udp, nil, 10240);
}
sleep(5000);
threadexitsall(nil);
}
---
cpu% 6.out | grep end | wc -l
33
sometimes little more or less
but
cpu% 6.out | grep start | wc -l
80
always.
Testing on Miller's RPi and 9front (amd64 & RPi 2)
Why does read() kill process?
Why not always?
Why number of 'ended' processes arond 33?
This is normal behavior?
How to fix the program so that the processes do not lost?
Can someone point me in the right direction?
Thanks!
Andrey
--
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Tfa6823048ad90a21-M6b9bfae581b00133c66b93c2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
