On Tue, 28 Jun 2022, adr wrote:
It's just to play with it, note that onnote should be just passed
once. I'll post another patch if things work ok.
Here it is. I'm doing sysfatal when malloc fails to be coherent
with the rest of libthread, but I don't think that's a good approach.
When those
On Tue, 28 Jun 2022, andrey100100...@gmail.com wrote:
Thanks for the patch.
It's just to play with it, note that onnote should be just passed
once. I'll post another patch if things work ok.
adr
--
9fans: 9fans
Permalink:
В Вт, 28/06/2022 в 15:28 +, adr пишет:
> Andrey, if you want to use different note handlers per process (with
> a big
> number of processes) using libthread, this may be helpful.
>
> The idea is this:
>
> An array of handlers for all processes which can be changed by all
> processes.
> When
On Tue, 28 Jun 2022, adr wrote:
This just evade going through the arrays twice. For the current
value of NFN it doesn't make too much a difference, note that this
structures are locked. It just was hurting my eyes.
Sorry for the noise, bad patch.
--- /tmp/main.c
+++ /sys/src/libthread/main.c
On Tue, 28 Jun 2022, adr wrote:
Andrey, if you want to use different note handlers per process (with a big
number of processes) using libthread, this may be helpful.
The idea is this:
An array of handlers for all processes which can be changed by all processes.
When a note is received by a
Quoth adr :
> Andrey, if you want to use different note handlers per process (with a big
> number of processes) using libthread, this may be helpful.
>
> The idea is this:
>
> An array of handlers for all processes which can be changed by all processes.
> When a note is received by a process,
Andrey, if you want to use different note handlers per process (with a big
number of processes) using libthread, this may be helpful.
The idea is this:
An array of handlers for all processes which can be changed by all processes.
When a note is received by a process, this array takes priority.
В Вт, 21/06/2022 в 11:26 +, 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
On Tue, 21 Jun 2022, andrey100100...@gmail.com wrote:
For example, let's remove note.c. You could obtain the same result
Just for clarity, you actually don't need to remove note.c to do
what I said below.
in your example (all processes using the same handler) using atnotify
because the
В Вт, 21/06/2022 в 11:26 +, 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
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:
On Mon, 20 Jun 2022, Skip Tavakkolian wrote:
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
Nice example, but I strongly
В Пн, 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
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
On Mon, Jun 20, 2022 at 8:57 AM wrote:
>
> В Пн, 20/06/2022 в 05:59 +, adr
В Пн, 20/06/2022 в 05:59 +, adr пишет:
> On Mon, 20 Jun 2022, adr wrote:
> > But I have something in mind for a case like
> > this, when all the processes are going to use the same handler
> > (that's why I was asking). Let me play with it a litle before I
> > share it.
>
> Ok, the idea is
The last mail got screwed, I'm resending this for clarity.
/sys/src/libthread/sched.c:
[...]
if(t == nil){
_threaddebug(DBGSCHED, "all threads gone; exiting");
cancelnotes(p->pid);
_schedexit(p);
}
On Mon, 20 Jun 2022, adr wrote:
But I have something in mind for a case like
this, when all the processes are going to use the same handler
(that's why I was asking). Let me play with it a litle before I
share it.
Ok, the idea is this: If in is bigger than zero in
threadnotify(int (*f)(void*,
В Пн, 20/06/2022 в 04:41 +, adr пишет:
> On Mon, 20 Jun 2022, andrey100100...@gmail.com wrote:
> > The note 'alarm' is needed to interrupt the system call on timeout
> > since system calls to lan 9 can be of a network nature, a notes is
> > indispensable.
> > A great example of this is the
On Mon, 20 Jun 2022, andrey100100...@gmail.com wrote:
The note 'alarm' is needed to interrupt the system call on timeout
since system calls to lan 9 can be of a network nature, a notes is
indispensable.
A great example of this is the read() system call on a udp-connection.
How else can this
В Пн, 20/06/2022 в 00:22 +0300, andrey100100...@gmail.com пишет:
> В Вс, 19/06/2022 в 16:41 +, adr пишет:
> > On Sun, 19 Jun 2022, andrey100100...@gmail.com wrote:
> > > Yes, you were absolutely right, the thread library needs some
> > > work.
> > >
> > > It is impossible to use multiple
В Вс, 19/06/2022 в 16:41 +, adr пишет:
> On Sun, 19 Jun 2022, andrey100100...@gmail.com wrote:
> > Yes, you were absolutely right, the thread library needs some work.
> >
> > It is impossible to use multiple processes with notes, due to the
> > exhaustion of the NFN limit.
>
> Andrej, what
On Sun, 19 Jun 2022, andrey100100...@gmail.com wrote:
Yes, you were absolutely right, the thread library needs some work.
It is impossible to use multiple processes with notes, due to the
exhaustion of the NFN limit.
Andrej, what are you going to do with alarm in the real thing?
You could
В Вс, 19/06/2022 в 10:32 +, adr пишет:
> On Sun, 19 Jun 2022, andrey100100...@gmail.com wrote:
> > No way. All processes must run simultaneously.
> > NFN limit cannot be bypassed.
>
> Yeah, that's why I said it was silly:
> > > > The solution is obvious, cancel the process' handlers before it
В Вс, 19/06/2022 в 14:40 +0300, andrey100100...@gmail.com пишет:
> В Вс, 19/06/2022 в 10:32 +, adr пишет:
> > On Sun, 19 Jun 2022, andrey100100...@gmail.com wrote:
> > > No way. All processes must run simultaneously.
> > > NFN limit cannot be bypassed.
> >
> > Yeah, that's why I said it was
В Вс, 19/06/2022 в 10:32 +, adr пишет:
> On Sun, 19 Jun 2022, andrey100100...@gmail.com wrote:
> > No way. All processes must run simultaneously.
> > NFN limit cannot be bypassed.
>
> Yeah, that's why I said it was silly:
> > > > The solution is obvious, cancel the process' handlers before it
On Sun, 19 Jun 2022, andrey100100...@gmail.com wrote:
No way. All processes must run simultaneously.
NFN limit cannot be bypassed.
Yeah, that's why I said it was silly:
The solution is obvious, cancel the process' handlers before it
exits so we don't run out of space.
This was really
В Вс, 19/06/2022 в 05:01 +, adr пишет:
> On Sun, 19 Jun 2022, adr wrote:
> > The solution is obvious, cancel the process' handlers before it
> > exits so we don't run out of space.
>
> This was really silly...
>
> > Now, is there any reason to not do that in threadexits() when it
> >
On 6/18/22 23:54, adr wrote:
> On Sat, 18 Jun 2022, Jacob Moody wrote:
>> I've attempted to reproduce it, trying to remove the libthread/notify
>> factors. I've come up with this:
>>
>> #include
>> #include
>>
>> static void
>> proc_udp(void*)
>> {
>>char resp[512];
>>char req[]
On Sat, 18 Jun 2022, Jacob Moody wrote:
I've attempted to reproduce it, trying to remove the libthread/notify
factors. I've come up with this:
#include
#include
static void
proc_udp(void*)
{
char resp[512];
char req[] = "request";
int fd;
int n;
int pid;
On Sun, 19 Jun 2022, adr wrote:
The solution is obvious, cancel the process' handlers before it
exits so we don't run out of space.
This was really silly...
Now, is there any reason to not do that in threadexits() when it
terminates the process?
Shouldn't threadnotify() cancel only the
Oh man... how silly, I know what's going on. We are using processes
not threads, so although we are sharing the same array of handlers,
they are registered for different processes. When the array is full
the next processes fail to register handlers _for_them_ so as andrey
rightly said, the
В Сб, 18/06/2022 в 09:22 +, 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
В Сб, 18/06/2022 в 06:53 -0600, Jacob Moody пишет:
> 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
> > > >
В Сб, 18/06/2022 в 08:37 +, adr пишет:
> 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
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
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
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
В Пт, 17/06/2022 в 21:15 +, adr пишет:
> 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
>
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.
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()
В Пт, 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
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
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
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,
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
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:
> > >
В Пт, 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 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
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
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):
>
>
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"))
51 matches
Mail list logo
