В Сб, 18/06/2022 в 09:22 +0000, adr пишет:
> 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?
Atnotify and threadnotify have different implementation.
it seems that threadnotify is for processes with shared memory,
atnotify for fork() (no shared memory).
But then it is not entirely clear why lock() is used in atnotify?
Regards,
Andrej
------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Tfa6823048ad90a21-Mfea7f52ccd99974d957af810
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
