On 6/18/22 03:22, adr wrote:
> On Sat, 18 Jun 2022, adr wrote:
>
>> On Sat, 18 Jun 2022, andrey100100...@gmail.com wrote:
>>
>>> ---------------------------------------------
>>>
>>> cpu% 6.out | grep end | wc -l
>>> 33
>>>
>>>
>>> Problem in unregistered handlers.
>>
>> But unregistered handlers shouldn't be a problem. The process is
>> been killed when alarm sends the note. That's why the code worked
>> removing the read statement, the alarm is set off and the note is
>> not sent before the process ends. I just don't see why the process
>> is been killed. The documentation describes another behavior. To
>> me it smells like bug barbecue (corrupted onnote?). Maybe I got
>> something wrong, bear with me.
>>
>>>> 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.
>>>
>>> I'm don't understand how handler in threadmain would solve the problem.
>>> I need in 'alarm' on per process basis.
>>
>> You need alarm() in every process, but you don't need to register the
>> same handler 80 times!
>>
>> adr.
>
> I think there is some confussion here, so I'll explain myself a
> little more.
>
> Lets change your last example to not use libthread:
>
> #include <u.h>
> #include <libc.h>
>
> int
> handler_alarm(void *, char *msg)
> {
> if(strstr(msg, "alarm")){
> return 1;
> }
>
> return 0;
> }
>
> int
> test(void)
> {
> if(atnotify(handler_alarm, 1) == 0){
> fprint(1, "handler not registered\n");
> }
>
> alarm(10);
> fprint(1, "start\n");
> sleep(40);
> fprint(1, "end\n");
> alarm(0);
>
> return 0;
> }
>
> void
> main()
> {
> for(int i = 0; i < 80; i++){
> test();
> }
>
> exits(nil);
> }
>
> You see, after the NFNth iteration of test(), onnot[NFN] in atnotify
> will be full, the handlers wont be registered but the code will
> work without any problem. It doesn't matter, the first handler in
> onnot[] will be executed. I fact you only need one handler there, not
> 80, you should move atnotify to main.
>
> The same should be happening with libthread. I'm really the only
> one smelling a bug here?
No, you've got me convinced something much more wrong is going on.
Because you're right, our read children shouldn't just be gone,
we should return from read with an error and then print the "end" line.
I've attempted to reproduce it, trying to remove the libthread/notify
factors. I've come up with this:
#include <u.h>
#include <libc.h>
static void
proc_udp(void*)
{
char resp[512];
char req[] = "request";
int fd;
int n;
int pid;
fd = dial("udp!185.157.221.201!5678", nil, nil, nil);
if(fd < 0)
exits("can't dial");
if(write(fd, req, strlen(req)) != strlen(req))
exits("can't write");
pid = getpid();
fprint(1, "start %d\n", pid);
n = read(fd, resp, sizeof(resp)-1);
fprint(1, "end %d %d\n", pid, n);
exits(nil);
}
void
main(int, char**)
{
int i;
Waitmsg *wm;
for(i = 0; i < 10; i++){
switch(fork()){
case -1:
sysfatal("fork %r");
case 0:
proc_udp(nil);
sysfatal("ret");
default:
break;
}
}
for(i = 0; i < 10; i++){
wm = wait();
print("proc %d died with message %s\n", wm->pid, wm->msg);
}
exits(nil);
}
This code makes it pretty obvious that we are losing some children;
on my machine this program never exits. I see some portion of the
readers correctly returning -1, and the parent is able to get their
Waitmsg but not all of them.
Thanks,
moody
------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Tfa6823048ad90a21-Ma4f311286087163ef1e2565e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
