В Вт, 21/06/2022 в 11:26 +0000, adr пишет:
> On Tue, 21 Jun 2022, andrey100100...@gmail.com wrote:
> > ? ??, 20/06/2022 ? 15:29 -0700, Skip Tavakkolian ?????:
> > > It's cleaner to use channels with separate io and timer threads
> > > that
> > > do their syscalls via ioproc; this one doesn't require any
> > > changes to
> > > libthread:
> > >
> > > https://gist.github.com/9nut/aaa9b9b6a22d69996b75ccdc6e615c61
> >
> > Thanks for the work you've done!
> > Yes, I have considered this possibility.
> > But it was precisely this kind of code bloat that I wanted to
> > avoid.
>
> It looks like code bloat, but it really isn't. It is doing the job
> with the tools of the api according to the paradigm designed in
> libthread. That's why the word "cleaner" is completely correct.
And one more problem:
cpu% 6.out -a 'udp!52.43.121.77!10011' -n 250 -t 7 | grep time | wc -l
6.out 50974: warning: process exceeds 100 file descriptors
6.out 51053: warning: process exceeds 200 file descriptors
6.out 51238: warning: process exceeds 300 file descriptors
6.out 51314: warning: process exceeds 400 file descriptors
6.out 51342: warning: process exceeds 500 file descriptors
6.out 51414: warning: process exceeds 600 file descriptors
6.out 51158: warning: process exceeds 700 file descriptors
250
cpu% ps | grep 6.out | wc -l
751
Сonsumes three times more resources than it should.
>
> I think note.c was added to resolve some particual case, and for
> the state of note.c, I don't think it has been used too much.
>
> For example, let's remove note.c. You could obtain the same result
> in your example (all processes using the same handler) using atnotify
> because the notes are registered to the children when proccreate
> uses rfork:
>
> void
> threadmain(int argc, char *argv[])
> {
> atnotify(handler_alarm, 1);
>
> ./5.out | grep end | wc -l
> 80
>
> If you have to use a different handler for each processes you can't
> use atnotify because of RFMEM, but you can use the syscalls notify
> and noted:
>
> #include <u.h>
> #include <libc.h>
> #include <thread.h>
>
> static void
> handler_alarm(void *, char *msg)
> {
> if(strstr(msg, "alarm")){
> print("yes");
> noted(NCONT);
> return; /* just in case */
> }
> noted(NDFLT);
> }
>
> static void
> proc_udp(void *)
> {
> char resp[512];
> char req[] = "request";
> int fd;
> notify(handler_alarm);
> 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);
> }
>
> ./5.out | grep end | wc -l
> 80
>
> Threadnotify is trying to do an atnotify that works with RFMEM,
> but to do that onnote should be allocated to grow or shrink (or
> have a size thinking in the maximum number of processes the program
> could spawn, not the number of handlers a process could register
> as in atnotify), instead of pointers to handlers, it should be an
> array of pointers to arrays of handlers allocated by each process.
>
> Now again, does the notes mechanism actually fit in libthread? If
> it does it should be fixed, if not removed.
>
Regards,
Andrej
------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Tfa6823048ad90a21-M813e896da7e1be8ab8338198
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
